29

Ok..So I have started studying about MQ and its purpose/usecase etc... My existing application (Web made using JSP etc..) uses RestFUL interface to communicate with a remote server and to post/receive data from the server.

We often have to deal with the connectivity of the remote server.The synchronization problem is always there..

Message sent from our end.But Remote server went down. Or vice versa.

I came across the MQ thing and found it to be reliable when delivering and receiving messages from remote server is concerned.

But again, using REST I think the entire need for MQ appears to be a bit hazy.. I am basically looking for few of the differences between MQ and RestFUL..

I read on other blog post that with the advent of increasing research in the RestFUL domain, the MQ's will slowly loose pace..

I don't have much idea about MQ so won't comment anything but surely working with RestFUL is fun.

Would appreciate if someone provides differences between using RestFUL and MQ.

Danubian Sailor
  • 1
  • 38
  • 145
  • 223
AngelsandDemons
  • 2,823
  • 13
  • 47
  • 70
  • This one is somehow related to your question http://stackoverflow.com/questions/16838416/service-oriented-architecture-amqp-or-http/17296885 – pinepain Oct 09 '13 at 12:31

3 Answers3

38

One of the biggest differences is that REST implies synchronous processing while MQ is more often asynchronous. As you already mentioned, MQ is a way to decouple producer and consumer so that they don't have to be online at the same time but the system would still be functioning as a whole. If your use case implies a low-latency response (like a user with a browser) you need synchronous semantics and in this case MQ is just a different protocol. If latency is not a concern, or there's messaging goes only in one direction MQ may be a very viable alternative. One thing MQ provides for free is load balancing (and some level of HA) on the consumer side.

REST is much more flexible in terms of client/server compatibility. You can run a REST client nearly on every platform, which is not the case with MQ. I guess, this is the reason why some people claim MQ is getting obsolete. For this reason MQ is not good for public APIs. However, for communication between two server systems MQ still remains a very good option. A unique feature of REST is that it allows you to fully mimic the WEB behavior of your resources (hypermedia), i.e. one resource contains a reference to the other and so on. MQ cannot provide anything like that.

Performance may be another concern. I cannot give any exact figures, but MQ tends to have greater throughput.

In some rare cases due to security requirements clients cannot connect directly to the server. In such cases MQ is pretty much the only way to send data to the server.

To summarize, as a rule of thumb I would use REST

  • for public APIs or
  • where synchronous processing is needed

MQ

  • when only a limited amount of server side systems is involved and
  • asynchronous processing is acceptable or
  • REST performance is not enough
kkamenev
  • 939
  • 9
  • 12
  • 1
    Where did you read that REST is sync? https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf This entirely depends on the client implementation... If you need guaranteed delivery, then the source of the message has to be the service and the receiver the client. That way you can do something similar than an MQ. – inf3rno Oct 12 '18 at 23:45
  • 5
    @inf3rno All I was trying to say was that with REST it is much easier to use synchronous request-response style, whereas with messaging asynchronous is easier and more natural. With some effort you can do async with REST and sync with MQ. The question is, would the benefits be worth the effort in your particular circumstances. – kkamenev Oct 15 '18 at 08:58
  • @inf3rno there alot to considers when implementing REST over HTTP to be as asynchronous. Retry, Payload identifier, buffering, channel auth and even delivery cluster are all non differentiated functions. These are at best delegated the MoM or even data streaming platform. – Awan Biru Apr 14 '22 at 16:06
13

Both REST and MQ enable communicate between remote systems (and local).

In a REST communication the consumer and the REST service provider should be running for a communication to succeed. It is a point to point communication.

In MQ model the producer and consumer need not be running at the same time. The producers and consumers do not interact directly. The message broker takes care of handling the messages, persisting, it etc. Both point to point and publish-subscribe models are supported. In a publish subscribe model a message can be consumed by more than one consumer.

These are just some basic points that differentiate them. There are enough posts on SO that talk about REST and MQ.

techuser soma
  • 4,766
  • 5
  • 23
  • 43
  • Okk..Can anyone tell me say if the producer is not able to transmit the data to consumer (say suppose consumer is inactive), so MQ is storing all the messages in Queue. But what if the Producer goes down.What will happen to the MQ's and the messages. – AngelsandDemons Nov 30 '13 at 09:12
  • 2
    The producer can set a message as a persistent or a non persistent message. The messages are stored and delivered by the broker and is not affected by producer going down. Unconsumed persistent messages remain in the persistent store even if the broker goes down. They will be sent to the consumer once the broker is back up. Non persistent messages will be lost once broker goes down. – techuser soma Dec 02 '13 at 12:52
5

Both are abstractions but on different levels Your application can provide RESTful API, but under the hood it will utilize various components, among which is message queues.

Short and dirty: RESTful declares best practices how to build app or components, MQ served for messaging between components.

You may be confused with RPC, but in a web context it's not the same as MQ.

pinepain
  • 12,453
  • 3
  • 60
  • 65