Is REST Best in a Microservices Architecture?
capgemini.github.io
capgemini.github.io
REST is synchronous in terms of request/reply, but that doesn't mean that higher-level actions must (or even should) be restricted to that cycle, so subprocesses like the notification should never have to block the stock update. Even if the requester needs to be informed about that, the stock updating mechanism should instead create a new Resource that tracks the notifications, and send the link to it so that the client can see how it's going.
But this wouldn't be necessary, because I agree that the stock updating shouldn't have to known about the notifications - but again, REST does not require it to!
The way to architect this using REST would be for the Notification Service to track how the stock of each product is currently. Since polling each product is inefficient, the stock manager could offer a feed that lists the latest stock updates, just like blogs do with posts.
This doesn't require a SPOF like a messaging bus, it doesn't suffer from the "service going pop" problem (since we've eliminated the dependency the inventory service had on the email system) and it's proven to work at a huge scale - the web.
How does it differ from polling?
An alternative would be for the Inventory system to allow the Email system to register a callback URL (aka Webhook) with it that gets called when the stock updates - allowing for push events while maintaining a decoupled architecture -, but that is only useful if the stock only gets updated sporadically, as you should still have a resource that can be polled, in case the Email system dies and then needs to check what happened when it was offline.
You point about the SPOF is that you prefer distributed state inside the individual services over having events stored in the message bus? Then you're back to high coupling between the inventory manager and notifier, if the former is down the latter won't be able to send out any notifications.
The coupling that should be eliminated is the reverse, ie., the inventory being unable to update stock if the notifier is down, which the article claimed was inevitable using REST. I tried to show it isn't.
Regarding the message bus, I actually meant the broker, which is the SPOF being introduced in the proposed architecture.
I'm currently working at a startup that has about 15 microservices and there are a few different strategies that we use to solve the problems being described in this article:
We do use HTTP REST style requests when one service needs to fetch data from another service on the fly (usually in response to a user query), but we put in timeouts and proper error handling in case the dependent service is misbehaving. We strive for a "minimally broken" experience by allowing parts of the experience to degrade if one microservice is over capacity or broken, and have designed our response to allow us to return at least some data as long as part of the system is still working. This solves the "coupling", and "when microservices go pop" problem in the article.
REST should be considered to be the interface for anything requiring realtime feedback, but not everything does require immediate processing, or immediate feedback. So for example there is no reason why the notification service should block anything as depicted in the authors example. The notification service could accept a POST request to dispatch the notification and immediately return a 200 response after placing the notification onto a queue. Then it can process the queue in the background in a non blocking manner. At some later point in time if a delivery receipt is absolutely required there can be a callback hook into the other service.
REST makes for a very nice interface when used in an appropriate setting, but it isn't necessarily the best thing for all parts of the microservice communication. But neither is a service bus, or pipeline the best implementation for everything. The most masterfully designed backend will use REST when that is appropriate, and use a messaging/queue system when that is appropriate. Any non trivial backend will probably require both.
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.
Of course, above described approach is just an (opinionated) option and by no means the only, or best solution. Cockcroft defines a microservices architecture as a service-oriented architecture composed of loosely coupled elements that have bounded contexts. Loosely coupled meaning you can develop, update, and deploy separately. Bounded contexts meaning you can understand and update the microservice’s code without knowing anything about the internals of its peers. I think this is the best description as it leaves completely open how one would achieve this. In other words, as long as it works for your situation it's fine.
[0] http://writings.quilt.org/2014/05/12/distributed-systems-and...
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.
...Phew! Turns out it's really "Is request-response the best Microservices architecture?"
Now, REST is all over my life, and I have literally never used SOAP since that training.
Although it's always possible to knock something up to get the job done, a developer working in (e.g.) XSLT is not necessarily in his or her comfort zone when working with remote services, and that tends to cause delays and other headaches.
Otherwise, though, I'm all in favour of it as an architectural choice.
And I'm OK with those being separated - to me, the more choice I have around techs used provides more competition for cleaner, easier configuration of said tech.