使用阻塞REST请求来实现发布/订阅 [英] Using blocking REST requests to implement publish/subscribe

问题描述

我最近一直要求调查与谁愿意做电话事件（例如线路振铃，分机应答，呼叫清除）可使用RESTful Web服务的电话系统供应商整合的可行性。

I've recently been asked to investigate the feasibility of integrating with a phone system vendor who wants to make phone events (e.g. line ringing, extension answered, call cleared) available using a RESTful web service.

我指出，REST是一种请求/响应协议，他们正在做的发布/订阅。他们建议的解决方案是使一个HTTP REST请求这会阻止并最终如果当一个事件是可利用的回应 - 或超时

I pointed out that REST is a request/response protocol and they were doing publish/subscribe. The solution they were suggesting was to make an HTTP REST request which would block and then eventually respond if and when an event was available - or time out.

无论哪种方式，另一个请求将作出获取下一个事件，并如此循环往复。

Either way, another request would be made to get the next event and so on ad infinitum.

这个想法让我畏缩，但我确信，在iPhone的推电子邮件操作这种方式。

This idea made me cringe, but I was assured that the iPhone "push" e-mail operates this way.

这是一个合理的使用REST的？

Is this a reasonable use of REST?

推荐答案

我会说，它不与REST架构风格飞得好（主要是因为REST它约束到无状态的客户端服务器交互）。然而，网络是丰富与做长轮询解决方案，以及它或多或少作品，尽管在纤维网的精神不被的

I would say that it doesn't fly well with the REST architectural style (mainly because REST constrains it to stateless client server interactions). However, the web is abundant with solutions that do long polling, and it more or less works, in spite of not being in the spirit of the web.

首先，在体系结构的注意事项：实现REST内的pub / sub仅仅意味着出版商增加了项目，然后是提供给用户的列表。订户轮询列表。有各具特色这确保一次一次且仅-同时保持消息秩序的和的（形式）保证交付，尽管异步方式。它扩展真的很好，真的是有弹性的。

First, a note on architecture: Implementing pub/sub within REST merely means that the publisher adds items to a list which then is made available to subscribers. Subscribers poll the list. There are ways of crafting this to ensure once-and-only-once while maintaining message order and (a form of) guaranteed delivery, albeit asynchronous. It scales really well, and is really resilient.

我的第一条建议是使它可选，所以不能执行长轮询（或不愿）的客户可以这样做。我甚至会走这么远说，如果一个通用的客户端（如谷歌）的默认会的不的执行长轮询，并且该服务器通过一个特殊共享的方式踢长轮询您的客户端和服务器之间的了解。这种共识可以是自定义介质类型或自定义链接关系，甚至是自定义HTTP标头一般客户不会知道。那些支持你的长轮询的客户将是coded到发现长轮询的能力，并在必要时调用它，回落到常规轮询如果长期调查失败（如中介阻断它不知）。

My first piece of advice would be to make it optional, so that clients that can't perform long polling (or don't want to) can do so. I would even go so far as to say that if a generic client (like Google) the default would be not to perform long polling, and that the server kicks the long polling in by way of a special shared understanding between your client and the server. That shared understanding could be a custom media type or a custom link relation, or even a custom HTTP header that generic clients wouldn't know about. Clients that do support your long poll would be coded to discover the capabilities of long polling, and invoke it as necessary, falling back to regular polling if the long poll fails (e.g. an intermediary blocks it somehow).

而不是试图做到这一点在HTTP之上，我会建议使用非HTTP套接字为此，以不违反HTTP的意图，有效地使用HTTP作为传输协议。见的cometd。

And instead of trying to do this on top of HTTP, I would suggest using a non-HTTP socket for this, to not violate the intentions of HTTP and effectively use HTTP as a transport protocol. See cometd.

我的另一条建议是要问的问题是如何实时的客户必须是。如果几秒钟的延迟是可以接受的，那么你可以做很多事情定期轮询，甚至是极大量客户端，因为解决这个使用常规轮询的缓存特性。

My other piece of advice would be to ask the question how "real time" your clients have to be. If a few seconds latency is acceptable then you can do a great deal with regular polling, even for extremely large numbers of clients, due to the cacheable nature of solving this using regular polling.

这篇关于使用阻塞REST请求来实现发布/订阅的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！