Is REST Best in a Microservices Architecture?
capgemini.github.io
Is REST Best in a Microservices Architecture?
1–10 of 51 posts
Re: Is REST Best in a Microservices Architecture?
#2The obvious solution is probably the best: Use an asynchronous framework (like node.js or asyncio) for the REST interface and wait for the completion of the task to return a response.
That process wouldn't handle all the details of the task, but it can wait for notification of the task via other means (celery, rabbitmq, redis, whatever...).
Personally I think REST is the best paradigm for most microservices. There is one exception: Data streams are inherently stateful and some kind of websocket/message passing is a lot more useful in that case.
Re: Is REST Best in a Microservices Architecture?
#3I just love the way that consultancies are selling micro services as though it's some big thing that will revolutionise their business. Like big data or the cloud before it.
Looking at the article it seems that you've got an event driven system at the end with some components / pieces of code handling events e.g. Update inventory, inventory updated.
Re: Is REST Best in a Microservices Architecture?
#4I just love the way that consultancies are selling micro services as though it's some big thing that will revolutionise their business. Like big data or the cloud before it. Looking at the article it seems that you've got an event driven system at the end with some components / pieces of code handling events e.g. Update inventory, inventory updated.
It seems to me that he just re-invented the enterprise service bus.
Re: Is REST Best in a Microservices Architecture?
#5I just love the way that consultancies are selling micro services as though it's some big thing that will revolutionise their business. Like big data or the cloud before it. Looking at the article it seems that you've got an event driven system at the end with some components / pieces of code handling events e.g. Update inventory, inventory updated.
[deleted]
Re: Is REST Best in a Microservices Architecture?
#6I just love the way that consultancies are selling micro services as though it's some big thing that will revolutionise their business. Like big data or the cloud before it. Looking at the article it seems that you've got an event driven system at the end with some components / pieces of code handling events e.g. Update inventory, inventory updated.
It seems to me that he just re-invented the enterprise service bus.
I disagree. The last version only had a message bus. Its an inversion of communication - instead of the Gateway knowing that it has to communicate to the other services, it just publishes an event and the inventory service knows that it has to listen to events from the Gateway (or even simpler: Just listen to 'inventory-updated' message).
Re: Is REST Best in a Microservices Architecture?
#7I just love the way that consultancies are selling micro services as though it's some big thing that will revolutionise their business. Like big data or the cloud before it. Looking at the article it seems that you've got an event driven system at the end with some components / pieces of code handling events e.g. Update inventory, inventory updated.
It seems to me that he just re-invented the enterprise service bus.
I agree. To me he just didn't talked anything about his topic. Althouth everything in this article does make sense, but what about the REST?
Re: Is REST Best in a Microservices Architecture?
#8The obvious solution is probably the best: Use an asynchronous framework (like node.js or asyncio) for the REST interface and wait for the completion of the task to return a response. That process wouldn't handle all the details of the task, but it can wait for notification of the task via other means (celery, rabbitmq, redis, whatever...). Personally I think REST is the best paradigm for most microservices. There is…
How about batching stuff?
Re: Is REST Best in a Microservices Architecture?
#9Earlier quoted context omitted.
It seems to me that he just re-invented the enterprise service bus.
I disagree. The last version only had a message bus. Its an inversion of communication - instead of the Gateway knowing that it has to communicate to the other services, it just publishes an event and the inventory service knows that it has to listen to events from the Gateway (or even simpler: Just listen to 'inventory-updated' message).
Why is that different from an ESB?
Re: Is REST Best in a Microservices Architecture?
#10Earlier quoted context omitted.
I disagree. The last version only had a message bus. Its an inversion of communication - instead of the Gateway knowing that it has to communicate to the other services, it just publishes an event and the inventory service knows that it has to listen to events from the Gateway (or even simpler: Just listen to 'inventory-updated' message).
Why is that different from an ESB?
IMHO ESBs have logic, transform events etc.