非 Restful 接口背后的 Restful API
我正在尝试寻找相关的最佳实践/规范/文献/等。解决在非静态外观（例如 XMPP API 或 Websockets 通道）后面使用静态 API（例如，标准 Rails 应用程序）的一般问题。
例如，我有一个宁静的 Rails 应用程序，我想公开一个只读异步接口。这是非常简单的事情，Rails 应用程序推送到 Redis pubsub 通道，该通道又从 node.js 中使用，并发送到 websocket 通道 (1)。现在，我该如何最好地让这个异步 api 读/写呢？我正在考虑客户端通过 websockets 通道发送到服务器的内容，基本上相当于序列化的 http 请求或轻量级 json 编码的有效负载，这些负载将依次进入 Resque 队列，然后从主应用程序中进行解析，但我想知道是否有我可以借鉴的以前的工作/规范/架构，或者只是我可能会忽略的更优雅的方法。
(1) 显然，您可以将“websockets”替换为“xmpp”，并且普遍关注的非静态接口背后的静态应用程序仍然适用。
预先感谢您的任何帮助。
I'm trying to find relevant best practices/specs/literature/etc. to the general problem of using a restful API (say, a standard Rails app) behind a non-restful facade, like a XMPP API or a websockets channel.
For example, I've got a restful Rails app, and I want to expose a read-only asynchronous interface. It's pretty straightforward stuff, with the Rails app pushing to a Redis pubsub channel, which is in turn consumed from node.js, and sent to a websocket channel (1). Now, how would I best go about making this asynch api read/write? I'm thinking of the client sending to the server, over the websockets channel, what basically would amount to serialized http requests or lightweight json-encoded payloads that would in turn go to a Resque queue and then would be parsed from the main app, but I'd like to know if there's previous work/specs/architectures I can build upon, or simply more elegant approachs I might be overlooking.
(1) Obviously, you could replace 'websockets' with 'xmpp' and the general concern, restful apps behind non-restful interfaces, would still apply.
Thanks in advance for any help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不确定除了呼叫/响应方法之外是否真的有任何区别。
例如，在网络世界中，对 REST 接口的所有调用通常都是从浏览器进行的，其中任何状态跟踪都是在与 Web 客户端打交道时在服务器端完成的。因此，客户端接口通常会发送大量数据（直接或通过 cookie 间接）以允许服务器重建调用的上下文。
通过 XMPP（bosh 或 direct）或 Websockets 进行调用时，您将需要执行相同的操作，因为客户端将与中间体（XMPP 组件或机器人）通信，该中间体接收构成请求的节，收集任何存储的状态然后将其传递给 REST。
在最基本的形式中，XMPP 机器人/组件只会获取传入的节，将其转换为 REST 调用，进行该调用，然后打包结果。
I'm not sure there really is any difference except in the method of call/response.
For example, in the web world all calls to a REST interface are normally made from the browser where any state tracking is done server side as your dealing with a web client. So the client interface normally sends a lot of data (either directly or indirectly via cookie) to allow the server to reconstruct the context of the call.
With the call happening over XMPP (bosh or direct) or Websockets you will need to do the same because the client will be talking to an intermediate, the XMPP Component or bot, that receives the stanza's that make up the request, gathering any stored state and then passing that on to the REST.
In the most basic form the XMPP bot/component will just take the incoming stanza, translate it to a REST call, make that call and then package up the result.