REST 用于低延迟消息传递。
为什么你没有看到更多的人使用 REST 架构作为客户端服务器系统。 你看到人们使用套接字、TIBCO RV、EMS 或 MQ，但我还没有看到太多基本的 REST 架构，
有人知道为什么你会避免使用这种架构进行客户端/服务器通信以实现高吞吐量/低延迟吗？
why dont you see more people using REST architecture for client server system. You see people using sockets, or TIBCO RV or EMS or MQ but i haven't seen much basic REST architecture
does anyone know any reason why you would avoid using this architecture for client / server communication for high through put / low latency
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
REST 并不适合解决所有问题。
REST 最适合资源管理。 如果您正在编写 Web 服务（如客户端-服务器系统），那么您会发现您需要诸如与语言无关的数据表示、参数验证、客户端/服务器代码生成、错误处理、访问控制等功能。 REST 基本上要求您自己编写这些东西。
另一方面，它增加了HTTP层。 您可以无缝集成代理、缓存等，但由于 HTTP 标头、网络服务器前端等，您确实会损失一些速度。
REST is not a good fit for every problem.
REST is best for Resource management. If you are writing web services (as with a client-server system) then you find you want things like language-agnostic data representation, argument validation, client/server code generation, error handling, access controls. REST basically requires you to code those things yourself.
On the other hand, it adds the HTTP layer. You get seamless integration of proxies, caching etc, but you do lose some speed due to HTTP headers, the webserver frontend, etc.
我不知道我一定会避免它，但我可以想到为什么我可能不选择它来提供高吞吐量、低延迟服务的几个原因。 首先，您必须处理整个网络堆栈才能将消息发送到您的服务。 这可能会引入许多不必要的层和服务，从而延迟消息。 自定义服务只需要支持服务本身所需的协议层。
其次，除非您的服务是 Web 服务器上托管的唯一服务，否则您将与其他请求竞争您的消息的服务。 虽然为您的服务提供自定义端点可能无法解决所有资源争用问题，但至少您不必竞争从其他服务访问您的端点。
第三，自定义协议只需要支持实际的服务相关协议信息，并且可能会导致更小的数据包大小，因为您不需要支持额外的 HTTP 协议开销。 这尤其会影响交换小消息的协议，因为标头信息将占消息大小的较大部分。
I don't know that I would necessarily avoid it but I can think of a couple of reasons why I might not choose it for a high through-put, low latency service. First, you have to deal with the entire web stack to get your message to your service. This could introduce a number of unnecessary layers and services that would delay messages. A custom service need only support the protocol layers required by the service itself.
Second, unless your service is the only service hosted on the web server, you'll be competing with other requests for your messages to be serviced. While having a custom endpoint for your service may not solve all resource contention problems, at least you don't have to compete for access from other services to your endpoint.
Third, a custom protocol need only support the actual service-related protocol information and may result in smaller packet sizes because you don't need to support the additional HTTP protocol overhead. This would particularly effect protocols that exchange small messages as the header information would be a larger fraction of the message size.