RESTful v/s MQ.除了保证交付之外的差异和其他主要功能 [英] RESTful v/s MQ. Differences and other key features apart from Guaranteed Delivery
问题描述
好的..所以我已经开始研究 MQ 及其用途/用例等...我现有的应用程序(使用 JSP 等制作的 Web)使用 RestFUL 接口与远程服务器通信并从服务器发布/接收数据.
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.
我遇到了MQ这个东西，发现它在发送和接收来自远程服务器的消息时是可靠的.
I came across the MQ thing and found it to be reliable when delivering and receiving messages from remote server is concerned.
但同样，使用 REST，我认为对 MQ 的整个需求似乎有点模糊......我基本上是在寻找 MQ 和 RestFUL 之间的一些区别..
我在其他博客文章中读到，随着 RestFUL 领域研究的增加，MQ 将慢慢放慢步伐.
I read on other blog post that with the advent of increasing research in the RestFUL domain, the MQ's will slowly loose pace..
我对 MQ 不太了解，所以不会发表任何评论，但使用 RestFUL 肯定很有趣.
I don't have much idea about MQ so won't comment anything but surely working with RestFUL is fun.
如果有人提供使用 RestFUL 和 MQ 之间的区别，将不胜感激.
Would appreciate if someone provides differences between using RestFUL and MQ.
推荐答案
最大的区别之一是 REST 意味着同步处理，而 MQ 通常是异步的.正如您已经提到的，MQ 是一种分离生产者和消费者的方法，这样他们就不必同时在线，但系统仍然可以作为一个整体运行.如果您的用例意味着低延迟响应(例如使用浏览器的用户)，您需要同步语义，在这种情况下 MQ 只是一个不同的协议.如果延迟不是问题，或者只有一个方向的消息传递，MQ 可能是一个非常可行的替代方案.MQ 免费提供的一件事是消费者端的负载平衡(和某种级别的 HA).
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 在客户端/服务器兼容性方面更加灵活.您几乎可以在每个平台上运行 REST 客户端，而 MQ 并非如此.我想，这就是为什么有些人声称 MQ 已经过时的原因.因此，MQ 不适用于公共 API.但是，对于两个服务器系统之间的通信，MQ 仍然是一个非常好的选择.REST 的一个独特功能是它允许您完全模仿资源(超媒体)的 WEB 行为，即一个资源包含对另一个资源的引用，依此类推.MQ 无法提供类似的东西.
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.
性能可能是另一个问题.我无法给出任何确切的数字，但 MQ 往往具有更大的吞吐量.
Performance may be another concern. I cannot give any exact figures, but MQ tends to have greater throughput.
在极少数情况下，由于安全要求，客户端无法直接连接到服务器.在这种情况下，MQ 几乎是向服务器发送数据的唯一方式.
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.
总而言之，根据经验，我会使用 REST
To summarize, as a rule of thumb I would use REST
- 用于公共 API 或
- 需要同步处理的地方
MQ
- 当只涉及有限数量的服务器端系统时，并且
- 可以接受异步处理或
- REST 性能不够
这篇关于RESTful v/s MQ.除了保证交付之外的差异和其他主要功能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
