REST用于低延迟消息传递。

Question

为什么你看不到更多的人使用REST架构作为客户端和服务器系统。您看到人们使用套接字、TIBCO RV、EMS或MQ，但我还没有看到多少基本的REST架构

有没有人知道为什么您要避免将此体系结构用于高吞吐量/低延迟的客户端/服务器通信

Answer 1

我不知道我是否一定会避免它，但我可以想到几个原因，为什么我可能不会选择它作为一个高吞吐量，低延迟的服务。首先，您必须处理整个web堆栈，以便将消息发送到您的服务。这可能会引入许多不必要的层和服务，从而延迟消息。自定义服务只需要支持服务本身所需的协议层。

其次，除非您的服务是web服务器上托管的唯一服务，否则您将与其他请求竞争要为您的消息提供服务。虽然为您的服务拥有一个自定义端点可能无法解决所有资源争用问题，但至少您不必争用其他服务对您的端点的访问。

第三，自定义协议只需要支持实际的与服务相关的协议信息，并且可能会导致较小的数据包大小，因为您不需要支持额外的HTTP协议开销。这将特别影响交换小消息的协议，因为报头信息将是消息大小的较大部分。

Answer 2

REST并不适用于所有问题。

REST最适合资源管理。如果您正在编写web服务(与客户端-服务器系统一样)，那么您会发现您需要语言无关的数据表示、参数验证、客户端/服务器代码生成、错误处理、访问控制等功能。REST基本上需要你自己编写代码。

另一方面，它添加了HTTP层。你得到了代理、缓存等的无缝集成，但由于HTTP报头、get服务器前端等原因，你确实失去了一些速度。