为什么 SOAP 不能使用 HTTP 缓存机制 [英] Why SOAP can't use HTTP caching mechanisms

问题描述

我正在从 SOAP 过渡到 REST，我想让我的同事相信这是一个很好的举措.我们不需要 SOAP 可以提供的额外安全机制.多年来，SOAP 和 WSDL 的开销对我们来说只是一个令人头疼的问题.

I am making a transition from SOAP to REST, and I would like to convince my colleagues that this is a good move. We don't need the extra security mechanisms that SOAP can provide. For us the overhead of SOAP and WSDL has only proven to be a headache over the years.

除了明显的简化之外，我们系统的一个真正有价值的优势是 HTTP 缓存机制.我已经阅读了有关该主题的内容，但我仍然不完全理解为什么这些缓存机制不能应用于 SOAP 消息.

Apart from the obvious simplifications, one really valuable advantage for our system would be the HTTP caching mechanisms. I have read things on the subject, but I still don't fully understand why these caching mechanisms can't be applied to SOAP messages.

是否仅仅是因为 REST 按照约定对 url 中的所有参数进行编码?由于 GET 调用也可以有一个带参数的主体，我知道它不受 REST 的限制，但是如果这样做，缓存机制就不起作用?

Is it simply because REST by convention encodes all the parameters in the url? Since a GET call can also have a body with parameters, I understand that it's not restricted for REST, but the caching mechanisms don't work if you do so?

推荐答案

SOAP 在使用 HTTP 作为传输机制时，通过 HTTP POST 请求发送.由于 HTTP POST 是非幂等的，因此不会在 HTTP 级别缓存.

SOAP, when using HTTP as the transfer mechanism, is sent via HTTP POST requests. As HTTP POST is non-idempotent, it is not cached at the HTTP level.

REST 可能被缓存，前提是相关请求是幂等的:GET、PUT 和(理论上)DELETE.任何 POST 请求仍然不会被缓存.也就是说，如果您打算为此做很多工作，您应该研究缓存如何检查它们是否仍然有效.特别是，ETag 标头 将是实现缓存的好方法，前提是您有一种廉价的方法来计算价值应该是.

REST may be cached, provided the requests in question are idempotent ones: GET, PUT and (theoretically) DELETE. Any POST requests still won't be cached. That said, if you are planning to do a lot of work with this, you should look into how caches check whether they are still valid. In particular, the ETag header will be a good way to implement caching providing you've got a cheap way to compute what the value should be.

仅仅是因为 REST 按照惯例对 url 中的所有参数进行编码吗?由于 GET 调用也可以有一个带参数的主体，我知道它不受 REST 的限制，但是如果这样做，缓存机制就不起作用?

Is it simply because REST by convention encodes all the parameters in the url? Since a GET call can also have a body with parameters, I understand that it's not restricted for REST, but the caching mechanisms don't work if you do so?

REST 没有规定任何特定机制来对 URL 中的请求参数进行编码.推荐是客户端从不进行任何 URL 合成:让服务器创建所有 URL(通过您想要的任何机制，例如嵌入路径或作为查询参数).您绝对不应该做的是让客户端向服务器发送正文的 GET！任何缓存都可能会丢失它.相反，当该请求不对应于对某些资源的简单获取时，您可以将该复杂文档 POST 或 PUT 发送到服务器，并在单独的阶段 GET 操作结果.

REST does not prescribe any particular mechanism for how to encode request parameters in the URL. What is recommended is that clients never do any URL synthesis: let the server do all the URL creation (by whatever mechanism you want, such as embedding within the path or as query parameters). What you definitely shouldn't do is have a GET where the client sends a body to the server! Any cache is likely to lose that. Instead, when that request doesn't correspond to a simple fetch of some resource, you POST or PUT that complex document to the server and GET the result of the operation as a separate stage.

将操作结果作为另一个复杂文档返回的复杂文档的 POST 几乎就是 SOAP 的编码方式.如果您想这样做，您不妨直接使用 SOAP，因为它在许多语言中都有更成熟的工具.如果您想以这种方式运行 REST，那么您可能在某处做错了……

A POST of a complex document that returns the result of the operation as another complex document is pretty much how SOAP is encoded. If you're tempted to do that, you might as well use SOAP directly as that's got much more mature tooling in many languages. If you want to run REST that way, you're probably doing it wrong somewhere…

这篇关于为什么 SOAP 不能使用 HTTP 缓存机制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！