Why (Again) HTTP Based REST?
When choosing a reactive architecture, is HTTP based REST the best optimal universal answer for every message exchange?
Not really
NO! God damn it, no! Of course it's not the silver bullet. Not even close. Even so, I feel like if there was an implicit rule that obliges every microservice to demand the HTTP/Rest combination. However, many other aspects should be taken in consideration before choosing the most appropriate one.
It's not even rare to see more than one IPC protocol coexisting at the same data flow.
This is it. You've just read what the whole text is about. It should be enough for you and it may save you a few minutes if you just accept if. But, if you insist, I can give you more reasons to believe me.
The (long lasting) hype of HTTP
This is what Martin Fowler says about microservices:
… each running in its own process and communicating with lightweight mechanisms…
Lightweight mechanisms, often HTTP… This is not a requirement.
I don't think this is how people have interpreted the text. It is, by far, the most used one regardless of the problem and the context.
We can see an HTTP RESTful API being chosen as the default solution everywhere. Whether it's because it is really easy to use, or because there are literally thousands of library implementing it. But the question that has to be answered is "why?". Is it kinda reproducing itself?
Call a spade a spade
Through a really short research of available packages in npm repository, I raised the most often chosen IPC protocols, their respective most popular libraries and their downloads of the last year.
Well, it's well known that npm is not the best source of truth. Nevertheless, it's important to stress that this is not an academic research and it's enough to highlight what this texts aims. The chosen IPC protocols and their libraries were:
- REST/HTTP, and the library express;
- SOAP, and the library soap;
- AMQP, and the library amqp;
- MQTT, and the library mqtt; and
- KAFKA, and the library kafka.
Of course it is a static chart, and these values may change over time. What will confirm or invalidate my points.
Anyway, the result is not a surprise at all. Whilst more than 4 millions of downloads of express were computed, only 50 thousand of amqp downloads were made. The discrepancy is really large and it should draw everyone's attention. (The other numbers won't be mentioned because the spreadsheet was lost. They were not that relevant anyway).
Given the huge combination of context/scenarios/data flow/consistency demand that the software development faces regularly, is it true that in 96% of the cases the HTTP/Rest combination is the most appropriate one?
Pros/Cons
It goes without saying that, when choosing adopting HTTP/Rest solution, countless of advantages can be found:
- HTTP is easy and familiar;
- Natural supports request/response communication;
- Large amounts of available libraries;
- Doesn't require a mediator system such as brokers, what simplifies the overall architecture; and
- Several tools to test the APU: curl, ordinary browsers, postman etc..
Nonetheless, the pros are not enough to take for granted that REST/HTTP is the default option. Of course, there is a real plethora of cons points:
- Request/response is the only supported method of interaction;
- There's no mediator system. Therefore, client and server should be up and aware of each other to exchange messages;
- The client has to know the address of every server it may want to send messages. This is not a trivial problem in modern applications. There are, as a matter of fact, service discovery mechanisms only to handle instances localization;
- Its synchronous nature implies a strong coupling between client and server;
- Server decomposition is a really hard job to do, when needed;
- It demands the combination of a lot of HTTP requests to compose complex informations;
- Misleading URL to filter query parameters fields;
- Overfetching, native waste of bandwidth when spare data is send along with the message;
- HTTP was not done with this in mind. This is not a problem per se. But it becomes one when we have to map HTTP verbs (get, post, patch… which one would you use to validate a payload?) and HTTP status code (200: OK, 201: Created, 404: Not found…) to REST needs; and, last but not least
- Adopt good practices to create endpoints is a pain in the ass.
Not convinced yet? Other than the before mentioned cons, there is still a huge list of other article stimulating an IPC reflection prior to an immediate choose of REST/HTTP:
- forget HTTP microservices;
- Data is no longer at REST;
- REST is the new SOAP;
- Is REST Best in a Microservices Architecture?; and
- How Synchronous REST Turns Microservices Back into Monoliths.
Conclusion
As seen above, the REST/HTTP paradigm as message exchange mechanism brings a lot of flaws. Some of these flaws can hurt more than help and can be avoided. Thus, it cannot be chosen as the silver bullet to solve every communication problem.
As a thumb rule, synchronous protocols, such as HTTP, are discouraged for promoting strong coupling among the microservices, what fragilizes the individual autonomy of the microservices, hence, the whole solution resilience is affected.
I am not saying REST/HTTP should never be used. It hurts to admit but it is, indeed, the best option in several situations. However, the IPC option involves a lot of other factors and can not be neglected.
My point is that a deep dive, considering every factor, has to be made before choosing the most appropriate protocol.
