使用消息传递进行写入和读取
我来自网络背景，我只需要处理 HTTP，所以请原谅我的无知。
我有一个应用程序，客户端可以在其中监听使用 stomp 的消息队列中的更改。以前，客户端只需要监听相关通道的消息，告诉他们服务器上的变化，并相应地更新自己。简单的东西。
现在要求客户端能够编辑数据并将这些更改推送回服务器。服务器上的数据已经通过 Restful 资源公开，所以我的第一个想法是让 REST 发出请求来更改服务器上的数据，但后来我开始想知道是否可以找到使用消息传递的解决方案。我可以打开另一个频道，客户端可以将更改发布到该频道，服务器可以订阅该频道并相应地更新自身。实现这一点显然很简单，但我希望有人提前向我指出一些潜在的陷阱。
我熟悉 REST，所以我想在 REST 上下文中提出一些问题：
- 我是否会将一组队列映射到每个资源的 REST/CRUD 动词，即 itemPostQueue、itemPutQueue、itemDeleteQueue？
- 那么 GET 如何使用队列请求读取数据呢？
- 我用什么来替换我的状态代码机制来捕获问题，或者我只是触发并忘记（吞下）或以某种方式在 Stomp 中使用错误/收据标头？
任何答案和建议将不胜感激。
问候，
克里斯
I come from a web background where I only have to deal with HTTP so please excuse my ignorance.
I have an app which where clients listen for changes in a message queue which uses stomp. Previously the client only needed to listen to the relevant channels for messages telling them about changes on the server and update themselves accordingly. Simple stuff.
There is now a requirement for the client to be able to edit data and push those changes back to the server. The data on the server is already exposed via restful resources so my first thought was just to make REST put requests to change the data on the server, but then I started to wonder whether I could find a solution using messaging. I could just open up another channel which the clients could publish changes to and the server could subscribe to that channel and update itself accordingly. Implementing this would obviously be simple but I would love to have some of the potential pitfalls pointed out to me ahead of time.
I am familiar with REST so I want to ask some questions in the context of REST:
- Would I map a group of queues to REST/CRUD verbs for each resource i.e. itemPostQueue, itemPutQueue, itemDeleteQueue?
- What about GET's how can I request data to read using a queue?
- What do I use to replace my status code mechanism to catch problems or do I just fire and forget (gulp) or use error/receipt headers in Stomp somehow?
Any answers and advise will be much appreciated.
Regards,
Chris
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
虽然我不清楚为什么您必须在这里使用消息传递，但有一些想法：
您可以像 itemPostQueue 一样映射到线路上的 REST，但这对于一个人来说可能会感觉不自然。消息导向的人。如果您使用某种具有保证语义和内置交付一次的队列，那么请继续使用该机制。对于购物车示例，您可以将 AddItem 消息放在网络上，并且您信任基础结构会将其一次性传送到服务器。
消息队列中没有直接的 GET 概念。你可以用一对消息来模拟它，我向你发送一个请求，你向我发回一个响应。这很像 RPC，但更进一步解耦。因此，我向您发送一个 PublishCart 请求，随后，服务器在客户端正在侦听的通道上发送一条 CartContents 消息。
状态代码比较复杂，通常分为两个阵营。首先是实际的队列库消息 - 就像处理任何正常的系统消息一样处理它们。其次，您可能有自己的消息想要放在线路上，以表明链中某个位置出现故障。
消息传递所做的一件事是显着解耦您的应用程序。与 HTTP 不同，HTTP 中你知道发生了什么事，通过队列，你可以向某人发送一封信。它可能会到达那里。邮递员可能会把它掉在雪地里。狗可能会吃它。如果一段时间内没有得到回复，你就尝试其他方式联系你的亲戚，或者拉回类比，联系服务器。监控队列基础设施的运行状况和队列深度等变得更加重要，因为它们是您现在依赖的管道。
祝你好运
While I am not clear on why you must use messaging here, a few thoughts:
You could map to REST on the wire like itemPostQueue, but this would likely feel unnatural to a message-oriented person. If you are using some kind of queue with a guaranteed semantic and deliver-once built in, then go ahead and use that mechanism. For a shopping-cart example, then you could put an AddItem message on the wire, and you trust the infrastructure to deliver it once to the server.
There is no direct GET like concept here in message queuing. You can simulate it with a pair of messages, I send you a request and you send me back a response. This is much like RPC, but even further decoupled. So I send you a PublishCart request and later on, the server sends a CartContents message on a channel that the client is listening to.
Status codes are more complex, and generally fall into two camps. First are the actual queue-library messages - deal with them just as you would any normal system message. Second you may have your own messages you want to put on the wire that signal failure at some place in the chain.
One thing that messaging does do is significantly decouple your app. Unlike HTTP, where you know that something happened, with a queue, you send a letter to somebody. It may get there. The postman might drop it in the snow. The dog might eat it. If you don't get a response in some period of time, you try other means to contact your relatives, or to pull back the analogy, to contact the server. Monitoring of the health of the queue infrastructure and depth of queues and the like take on added importance, as they are the plumbing that you are now depending upon.
Good Luck