What is the real difference between an API and an microservice?

Question

I am learning about microservices and I don't understand what the real difference between creating a REST API and creating microservices?
I’m working in Go, but my question applies over all languages.

Solution 1

The Microservices approach is about breaking your system ("pile of code") into many small services, each typically has its own:

• Clear business-related responsibility
• Running process
• Database
• Code version control (e.g. git) repository
• API (the protocol how other services / clients will contact the Microservice)
• UI

The services themselves are kept small so as your system grow, there are more services - rather than larger services.

Microservices can use REST, RPC, or any other method to communicate with one another, so REST or an API is really orthogonal to the topic of microservices...

Reference: What is an API? In English, please.

Solution 2

API = Application Programming Interface

Microservices = an architecture

In short

• Microservice should expose a well-defined API.
• Microservice is the way you may want to architect your solution
• API is what your consumers see.
• You can expose API without microservices in the backend (in fact, most non-training scenarios don't require microservices).

You may want to read http://samnewman.io/books/building_microservices/ before you decide on using microservices (unless this is for training purposes).

Solution 3

Microservice is well defined when you are following SOC - seperation of Concern on the entity/domain level ,where each entity / domain are independent of any other service.

for example user service will only be responsible for storing, updating and deleting user related informations.

Microservice backend and frontend microservice can further be splitted in 2 parts

1. frontend microservice which exposes rest endpoint just like Web API
2. backend microservice which actually perform all the operations.

Rest API is more of endpoints exposed to outer world and can be used with microservices as well, as explained above.

Solution 4

Microservices

A microservice architecture is about slicing an application logic into small pieces or "components" that can act between them and/or be exposed through an API.

API

A (web) application need to design the business logic with all set of object entities (model) and possible operations on them. An (Application Programming Interface][https://en.wikipedia.org/wiki/Application_programming_interface) is a way of making the requests to an application by exposing specific entry-points that are in charge of invoking the appropriate application operations.

ReST(ful) APIs ("ReST" as in Representational State Transfer) are APIs complying with at least these 5 constraints:

• User-interface is distinct from data storage and manipulation (Client-Server architecture)
• No client context is stored on the server ("stateless")
• Server responses must, implicitly or explicitly, define themselves as cacheable or not
• Client does not have to be aware of the layers between him and the server
• Response/request messages must be: be self-descriptive; allow to identify a resource; use representations allowing to manipulate the resources; announce available actions and resources ("Uniform interface").

"The real difference"

So, while these notions are obviously related, they are clearly distinct concepts:

• Being ReSTful or not, an API exposes operations provided by a server that might (but not necessarily) be shelled into smaller components (microservices).

• Also, while a typical web (ReST)API uses the HTTP protocol between the client and the server, components within a microservice architecture might communicate using other protocol(s) (e.g. WAMP, AMQP, JSON-RPC, XML-RPC, SOAP, ...)

Solution 5

The majority of the answers is based on the old-school understanding of API as a programmatic interface. Nowadays, this meaning is melted and start confusing people becuase some developers started (for simplicit or by mistake) interpred the API of an application as the application per se. In such case, it is impossible to distinguish between the modern API and Microservices. Nonetheless, we can say that an API-application can comprise many Microservices, the most of which interact within the application via Microservice's APIs while others may expose their APIs as Applications's APIs. Also, a Microservice (as a service) may not include other Microservices (services), but may orchestrate a composition of Microservices via API-bases invocations. Applications may contain Microservices but, in the best practices, may not contain other Applications.

View more solutions

Comments

[fm433403]

But before I create three APIs, but I don't understand how to modify them to make microservices of these

[Lech Migdal]

@fm433403 first question you should ask yourself is - what problems are you solving with microservices architecture? It's a tool for very specific set of challenges. A tool that doesn't come free. So make sure you understand the tool before you use it. Check e.g. samnewman.io/books/building_microservices

[fm433403]

So the ideal for a web application would be to create microservices for my internal problems and what I want to expose an API?

[Lech Migdal]

If I got your question right, the answer is yes. You expose API, which may be created with microservices architecture. Again, please make sure microservices are a good architecture for you and that you have microserivces of the right size (e.g. for specific Business Domain). You may want to check at some of the presentations of how Netflix does microservices, to see what is the size of microservices they use, e.g. here nginx.com/blog/…