6

问题

我们正在构建一个对服务采用 RESTful 方法的 SOA。一旦系统投入生产，我们将有许多客户使用该接口，包括内部和第三方系统。

我们希望能够在客户端应用程序提供的响应信息中消费和回显，例如：-

  • 会话 ID - 可以是 Java EE 会话 ID 或任何特定于客户端的内容，这对于支持团队和调试客户端问题以在我们所有的系统中跟踪它们很有用。
  • Transaction Id - 请求的唯一标识符，如果客户端异步调用服务或我们实现 202 Accepted 样式的长时间运行流程，我们可以将其回显给客户端以帮助客户端进行请求/响应关联。

潜在的解决方案

因此，坚持 RESTful 约束意味着我们需要利用 HTTP 来实现这一点，并且我们可以实现几个选项。

  • Pragma header - 为 transaction-id、session-id 等实现 extension-pragmas。这似乎是纯粹的解决方案，因为它使用了标准的 HTTP 标头，尽管我担心它会成为我们无法打扰的所有东西的倾销场好好想想。
  • X-My-Header - 我们需要的每个字段的自定义标题。可能被代理剥离，而不是核心 HTTP，所以感觉反休息
  • 在查询字符串或 XML/JSON 表示中 - 将字段添加到我们的所有资源中。因为它是一个操作参数，所以感觉它应该作为元数据而不是资源提供。
  • Cookies - 使用 Cookie 和 Set-Cookie 来保存自定义键值；在会话 id 的情况下很有用，因为大多数实现已经使用 cookie。每次都必须重新发送以支持客户端相关性，这会破坏使用 cookie 的意义。

答案

这有什么先例吗？我们疯了吗？在我的所有研究中，我是否缺少明显的东西？没有人真正关心部署后他们将如何支持他们的服务吗？我应该闭嘴走开吗？

我希望有人能帮忙。

PS对不起，如果这是一篇文章，建议确实说“具体”....

4

2 回答 2

2

哦，这很痛苦。我也去过那里。

好吧，交易、会话等元数据的想法是个好主意。至少对于日志记录。

问题是要设置符合各种公司策略和 SOA 基础架构的东西。

在 HTTP 的情况下，需要在最佳设计和最大互操作性之间进行权衡。

安全路径是在消息本身中对元数据进行编码。不是很好，而且这样的解决方案最终看起来有点像 SOAP，您有一个包含所有消息标题的信封。

我最终使用 X-header 来获取诸如事务 ID 之类的信息。但是，正如您所提到的，代理/b2b 网关等可能会剥离标头，您可以使用所有指定的开发框架、COTS 应用程序等来检索它们并不明显。因此，如果您这样做，您应该避免强制元数据运行解决方案 - 只是“很高兴拥有”。

饼干只不过是痛苦。它们可能很烦人，有时甚至对浏览器交互很有用，但在 SOA 场景中，这将是一个坏主意。很多事情都可能出错，调试跨组织是一件痛苦的事。

我还会避免将查询字符串与 POST 或 PUT 数据一起使用。根据 HTTP 规范，这是可能的。但在随机框架中实施时则不然。

于 2012-08-15T05:16:28.027 回答
0

您可以使用 GUID 并让客户端生成它并将其作为启动工作流/业务流程的任何请求的一部分传递。此 GUID 可用于跨参与工作流的多个组件进行关联。

于 2016-11-07T20:05:19.320 回答