Is REST Best in a Microservices Architecture?

I think you mean it handles a lot of the negatives.

REST is not the source of the problem being described in the article. The problem in the article is from bad application of REST.

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.

I don't know what the author of the article is reading, but the information I read says to use REST for your sync communication which require realtime feedback and are blocking anyway (like authentication). Then use message queue mechanisms for non-blocking/async stuff (e.g. Inventory update, packaging services, etc.). Amazon even has the services out of the box in sqs/sns but you can also use rabbitmq, zeromq, ironmq, or whatever.

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.

I might suggest that 202 is a better response in your example.

I liked Distributed Systems and the End of the API[0] by Chas Emerick. It discusses how HTTP (and other network-related) APIs are ill-suited for complex distributed systems and what can be done about that. The article talks mostly about CRDT and CALM, it does mention messaging queues as well.

[0] http://writings.quilt.org/2014/05/12/distributed-systems-and...