I've read many articles concerning microservices architecture and I was wondering when to use AMQP or REST.

I've read that loose coupling between services is a good thing and AMQP seems to be a good choice in that case. But if we use AMQP, this means that we do not need REST endpoints anymore (but it means that we lose the HATEOAS concept).

But is REST really a good way to build my services? Cause I won't use any endpoints... In which case one is better than the other one?

When should I use one or the other?

4 Answers 4


By discarding REST, you lose much more than just HATEOAS. If your microservices are public (and it's a good idea for them to be public or at least tend towards being public one day¹), using anything other than REST and SOAP would be problematic:

  • Some developers never used AMQP,

  • Some have used AMQP, but are often much more familiar with REST and SOAP,

  • AMQP libraries for some languages are not particularly straightforward,

  • Manual experimentation with the service is very limited: I can use CURL to do any request to Amazon S3; what should I install on my machine if I want to play with an AMQP variant of S3?

  • Debugging REST and SOAP is easy. I just track the HTTP exchanges and analyze them. Not sure what tools should I use to see to debug AMQP exchanges.

AMQP is great, but it's done for a very specific purpose of exchanges based on events. While it's technically possible to do RPC with AMQP, it's not its primary purpose.

The asynchronous aspect is important too. Sometimes it's a benefit: I don't want to block the user interface of an app while doing requests to servers. Sometimes, it just make things harder than they need to be: if I need to recover a file backup from Amazon S3 because the local one was corrupted, and then restore the backup, my batch file necessarily needs CURL to finish its job before continuing, and a synchronous operation (with a specific timeout) makes perfect sense.

Keep REST for primary operations:

  • Getting a product,

  • Storing an invoice,

and use AMQP for the tasks where messaging actually makes sense:

  • Processing all invoices from September and notify the app when the report is ready to be shown (given that the operation takes usually from two to ten minutes),

    The benefit of AMQP here is its asynchronous aspect. An HTTP request pending for ten minutes have a good chance of causing a timeout and other issues.

  • Dispatching the information that the backups were corrupted to every one who may be interested, such as the support people, the database administrators, the monitoring team, the developers of the application which uses this database, etc.

    The benefit of AMQP here is, among others, the ability to add the subscribers without changing the application which tracks backups and triggers the alert when it finds a corrupted one.

¹ A public web service isn't necessarily used by users outside a company. In large or medium-size companies, your service is often used by other divisions of the same company and has the same requirements as the one which would be used by any third party: it should mistrust any call (the fact that some guy you never heard of who calls your service works in the same company you do doesn't mean he will not exploit its security issues), it should be documented properly (because the same Indian guy doesn't necessarily know your phone number and doesn't necessarily know English), etc.

  • What about loading depending objects using AMQP ? Like the user related to a billing service (in a massive microservice architecture), strengh for asynchronicity VS REST hateoas (synchroneous) access ? Commented Jan 11, 2016 at 11:51

Use both.

REST style JSON web services are great for interoperablity with javascript, ios etc

AMQP is great for long running processes, events and orchestration of microservices.

But both are just communication wrappers for the actual service, you can expose the same service in multiple ways and probably should.

AMPQ can work well exposed over Websockets, which can look pretty much like a REST endpoint if you squint at it.

  • 1
    "if you squint at it" lol, that was great. Commented Dec 19, 2017 at 20:51

REST is a standard technology that particularly is suited for interoperability between components - this is the key part, its great for making a web service that someone else can consume. However, it suffers from the usual problems of such interoperability in that it is less efficient than a custom protocol.

If you're writing a back-end architecture where the services are only consumed by yourself, then you can use whatever protocol you like - you're no longer constrained by using one that is so interoperable. You can use a MQ or something more tightly coupled and performant. Which one you use depends on your use-case, a message bus is very good for distributed set of services that process data where the client doesn't care who gets the messages it sends out.

  • 2
    I don't agree, as far as I'm concerned they have cross purposes; you (generally) shouldn't expose AMQP over the public internet; it has a lot less auth facilities for one thing, and usually public internet users want responses from their activites. REST is ideally suited to public internet usage for this reason. The biggest difference though is that AMQP is asynchronous (synchronous like behaviours are possible, but it's not what MQs are for), and REST is synchronous (yes returning 202 is dictating asynchrony, but why did you use REST then? Probably because it's public.) Commented Oct 12, 2015 at 11:34
  • On a side note, exposing AMQP for websocket use so users get live realtime pushes instead of having to poll is actually a reason to do public AMQP; but again: Cross purposes, you don't do REST so consumers can get pushes, this is another scenario where you use AMQP for something REST can't do. Commented Oct 12, 2015 at 11:35
  • @JimmyHoffa I figured he was asking what to use to hook his webservers or clients or whatever to his microseervices on an internal LAN, not over the web - hence my point that REST is good for that, but if everything you are using is under your control, you can use whatever you like.
    – gbjbaanb
    Commented Oct 12, 2015 at 12:05
  • Yeah, that makes sense for sure; I read his question differently though: It seems he read about the idea of microservices, and doesn't understand the relevant reasons to choose AMQP vs REST. Internally you could use whatever you want, but there's still specific reasons to use AMQP vs REST even internally; services that want asynchrony should use AMQP internally, services that are synchronous (think a pure processing service: Raw Data in -> Processed data out) should be REST. There are distinct advantages and disadvantages to both IPC techs, you know them and should list them in your answer! :) Commented Oct 12, 2015 at 12:27

AMQP also supports point-to-point communication (for example, see the python-qpid-proton tutorial). You could implement a RESTful interface using that, since REST != HTTP.

AMQP also performs a lot better than HTTP.

Not the answer you're looking for? Browse other questions tagged or ask your own question.