0

我来自网络背景，我只需要处理 HTTP，所以请原谅我的无知。

我有一个应用程序，客户端在其中侦听使用 stomp 的消息队列中的更改。以前，客户端只需要收听相关频道的消息，告诉他们有关服务器上的更改并相应地更新自己。简单的东西。

现在需要客户端能够编辑数据并将这些更改推送回服务器。服务器上的数据已经通过 RESTful 资源暴露出来，所以我的第一个想法就是发出 REST put 请求来更改服务器上的数据，但后来我开始怀疑是否可以使用消息传递找到解决方案。我可以打开另一个通道，客户端可以将更改发布到该通道，服务器可以订阅该通道并相应地更新自身。实现这一点显然很简单，但我希望提前向我指出一些潜在的陷阱。

我对 REST 很熟悉，所以我想在 REST 的上下文中提出一些问题：

  • 我是否会将一组队列映射到每个资源的 REST/CRUD 动词，即 itemPostQueue、itemPutQueue、itemDeleteQueue？
  • GET 如何请求数据以使用队列读取？
  • 我用什么来替换我的状态码机制来捕获问题，或者我只是触发并忘记（gulp）或以某种方式在 Stomp 中使用错误/收据标头？

任何答案和建议将不胜感激。

问候，

克里斯

4

1 回答 1

0

虽然我不清楚为什么你必须在这里使用消息传递，但有一些想法：

您可以像 itemPostQueue 那样在网络上映射到 REST，但这对于面向消息的人来说可能会觉得不自然。如果您正在使用某种具有保证语义和内置交付的队列，那么请继续使用该机制。对于购物车示例，您可以将 AddItem 消息放在网络上，并且您相信基础架构可以将它一次传送到服务器。

消息队列中没有类似GET的直接概念。你可以用一对消息来模拟它，我给你一个请求，你给我一个响应。这很像 RPC，但更进一步解耦。因此，我向您发送了一个 PublishCart 请求，稍后，服务器在客户端正在侦听的通道上发送 CartContents 消息。

状态码比较复杂，一般分为两个阵营。首先是实际的队列库消息 - 像处理任何普通系统消息一样处理它们。其次，您可能有自己的消息要放在线路上，表明链中某个位置出现故障。

消息传递所做的一件事是显着地解耦您的应用程序。与 HTTP 不同，您知道某事发生了，通过队列，您可以向某人发送一封信。它可能会到达那里。邮递员可能会把它丢在雪地里。狗可能会吃掉它。如果你在一段时间内没有得到回应，你尝试其他方式联系你的亲戚，或者拉回类比，联系服务器。监控队列基础设施的健康状况和队列深度等变得更加重要，因为它们是您现在所依赖的管道。

祝你好运

于 2009-12-25T16:35:53.043 回答