RESTful API vs Microservice

Eric Huang
Sep 5, 2016 · 3 min read

Edit: a new great article about Microservice from Thoughtworks.

Edit: another great API design guide from Google.

Edit: my thoughts after reading on modularization

The architectural style of REST was first introduced in 2000, primarily designed to work well with HTTP/1.1. Its core principle is to define named resources that can be manipulated using a small number of methods. The resources and methods are known as nouns and verbs of APIs. With the HTTP protocol, the resource names naturally map to URLs, and methods naturally map to HTTP methods POST, GET, PUT, PATCH, and DELETE.

One day I was asked about the differences/relationships between RESTful API and the very hot Microservices. There are a lot of great articles talking about Microservices principles and designs, and RESTful API seems to be very similar to Microservices. However, Microservices is more about architectural whereas RESTful API focuses more on how to expose Microservices.

No matter how you implement Microservices, one of the main drivers is the hope for faster time to market so one of its key design goals is to create a decoupled, independent and small systems (allowing for the independent delivery of business value) each of which

  • is easy to understand / modify (because they are small)
  • is the only place having logic/business rule
  • does not expose any implementation details such as database to ensure loosely coupling; it also implies that the RESTful APIs or Functions that implement Aggregates within a bounded-context should belong to one Microservice because they are tightly coupled in terms of sharing lots of same high level design and architecture, i.e. programming language and frameworks, database access framework, etc. to reduce the complexity as you may not want to maintain a module or bounded context (i.e. Messaging service) that uses different technologies and tech stacks
  • can be deployed separately without affecting others as long as the interfaces stay same
  • a few more benefits (such as scale separately, choice of programming languages, etc.)
  • trade development complexity for boring but difficult operational complexity, i.e. cross-cutting concerns such as service discovery, service-to-service and origin-toservice security, observability (including telemetry and distributed tracing)

I do not like the idea of thinking of Microservices in terms of lines of code or number of methods, but in practice a bounded-context could be a great candidate for a Microservices. If delivering changes requires slow and expensive coordination, the architecture needs to be reviewed because it does not achieve the goals.

Isolation or fault-tolerant is one of the most important goals when designing a Microservices. If a system consists of a set of well-isolated Microservices, a failure in one of the Microservices will not affect the whole system. For instance, if a Microservices (such as member service) is a core service that a lot of other Microservices depend on, we need to think about how to design them to make sure the communication and interaction with the core service is fault-tolerant. The bounded context could help, by that I mean, each Microservices (such as messaging service) has its own definition of same model (such as member) and keeps / syncs them internally so it uses them without invoking the Microservices. The message broker could be also used as an intermediate between them when trying to invoke Microservices to change its state, and the data will become consistency eventually.

Therefore, Microservices is more about architectural and design style, and you may be able to implement a Microservices without RESTful API. However, RESTful API makes it easy to build a loosely coupled Microservices.


RESTful API was introduced prior to Microservices. It is one of the RPC protocols. One of the key ideas is that every object has a uniform interface. For example, objects are identified and manipulated via a pattern. In ASP.NET Web API world, objects are organised via Controllers, Actions and HttpVerbs attributes.

Unlike the library API (in the form of .dll), RESTful API (in practice the API exposed via HTTP endpoints)

  • is truly loosely coupled (as long as the interfaces and their semantics keep same, the API’s implementation on the server can change anytime without worrying about breaking its consumers and consumer side deployments)
  • is language-agnostic

Therefore, Microservices and RESTful API solve different problems but works together!

Written by

Passionate Technologist and Continuous Improvement Practitioner

More From Medium

Also tagged Software Design

Also tagged Software Design

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade