rest - 对采用二进制数据的无效操作的正确 HTTP 请求方法

Question

考虑一个没有副作用但以二进制数据作为参数的 Web API 方法。一个例子是一种方法，它告诉用户他们的图像是否经过 Photoshop 处理，但不会将图像或结果永久存储在其服务器上。

这样的方法应该是 GET或 POST ?
GET似乎没有推荐的在 URL 参数之外发送数据的方法，但该方法的行为暗示了 GET ，根据 HTTP 规范，它用于安全、无状态的响应。这在 REST 语义下变得特别受限，这意味着 POST方法在服务器上创建一个新对象。

Answer 1

This becomes particularly constraining under the semantics of REST, which imply that POST methods create a new object on the server.

而一个 POST request 意味着发送的实体将被视为“由 Request-URI 标识的资源的新从属”，没有要求这会导致创建新的 永久对象或任何此类新对象都由 URI 标识(因此，就客户端而言，没有新对象)。一个对象可以是 transient 的，代表例如的结果“向数据处理过程提供数据块，例如提交表单的结果”，并且在表示该对象的实体被发送后不持久化。

虽然这意味着 POST 可以 创建一个新资源，当然是最好的方法，当服务器为新资源提供其 URI(当客户端指定新 URI 时， PUT 是更合适的方法)它也可以是用于删除对象的情况(尽管再次删除可通过 URI 识别的单个*资源，那么 DELETE 更合适)，创建和删除对象，更改多个对象，这可能意味着您的厨房灯会变但是无论成功还是失败，响应都是相同的，因为从网络服务器到厨房灯的通信不允许关于成功的反馈。它真的可以做任何事情。

但是，您的直觉很希望它成为 GET : 而松散的 POST意味着我们可以为几乎每个请求为其提供一个案例(就像通过将 HTTP 用于类似 RPC 的协议(protocol)的方法所做的那样，本质上将 HTTP 视为一种传输协议(protocol))，这在理论上是不优雅的，在实践中效率低下并且定义笨拙。您有一个幂等函数，该函数仅取决于客户端感兴趣的内容，并且最明显地映射了 GET在几个方面。

如果我们可以将所有内容都放入 URI 中，那么 GET会很容易。例如，我们可以定义一个简单的整数加法，例如 http://example.net/addInts?x=1;y=2表示添加 71和 2因此成为代表数字 3 的永久不可变资源(因为 GET 的结果会随着资源的变化而变化，但该资源永远不会改变)，然后使用像 HTML 的 <form> 这样的机制或 javascript 以允许服务器通知客户端如何构造其他号码的 URI(以维护 HATEOS 和/或 COD 约束)。简单!

您的问题是您没有可以像数字 1 那样简洁地表示的输入。和 2可以上面。理论上你可以做类似 http://example.net/photoshoppedCheck?image=data:image/png;base64,iVBORw0KGgoAAAANSU… 的事情并因此创建一个表示检查结果资源的 URI。该 URI 将在图像中每 3 个字节有 4 个字符。虽然对 URI 长度没有绝对限制，但理论和实践都允许这种情况失败(理论上 HTTP 允许代理和服务器对 URI 长度设置限制，实际上他们确实这样做了)。

可以提出使用 GET 的论据。并以与使用 POST 相同的方式发送请求正文，有些网络服务器甚至允许您这样做。然而， GET被定义为返回一个实体，该实体描述了 URI 中标识的资源，并带有限制该实体如何进行描述的 header :由于请求正文不是该定义的一部分，所以 必须被您的代码忽略!如果您想改变这条规则，那么您必须考虑:

有些网络服务器会拒绝请求或剥离正文，因此您可能无法这样做。

如果您的网络服务器确实允许它，则未指定的事实意味着您无法确定升级不会“修复”此问题，因此会破坏您的代码。

一些代理会拒绝或取消请求。

一些客户端库肯定会拒绝允许开发人员将请求正文与 GET 一起发送。 .

所以这在理论和实践中都是禁忌。

关于除了 POST 之外我们唯一可以做的其他方法是有一个 URI，我们认为该 URI 代表未经过 Photoshop 处理的图像。因此，如果您 GET你得到一个描述图像的实体(显然它可能是实际图像，但如果我们扩展内容协商的概念，它也可能是其他东西)然后 PUT将检查图像，如果它被认为不是 photoshopped，它会以相同的图像和 200 响应。或者只是一个 204而如果它被认为是经过Photoshop处理的，它会回复 400因为我们已经尝试 PUT作为资源的 photoshopped 图像只能是非 photoshopped 图像。因为我们立即响应，所以同时请求不存在竞争条件。

坦率地说，这将是非常可怕的。虽然我认为我已经通过规范的文字为它做了一个案例，但它只是令人讨厌:REST 旨在帮助我们设计清晰的 API，而不是我们可以提供的过于聪明的 API的理由。

不，一路走到这里就是 POST将图像转换为固定 URI，然后返回一个描述分析的简单实体。

它作为 REST 是完全合理的( POST 基于该图像创建一个 transient 对象，然后用一个描述该对象的实体进行响应，然后该对象再次消失)。这是直接的。它尽可能高效(我们不能做任何 HTTP 缓存†，但大部分网络延迟将发生在上传而不是下载上)。它也适用于“处理某物”的一般用例， POST最初是为. (请记住，首先是 HTTP，然后 REST 描述了它为何如此有效，然后对 HTTP 进行了改进以更好地发挥这些优势)。

总之，虽然使 Web 应用程序远离 REST 的经典错误是滥用 POST当 GET 做任何事情时, PUT和 DELETE (也许是 WebDAV 方法)会更好，不要害怕在那些不符合要求的情况下使用它的力量，并且不要认为“资源的新下属”必须意味着一个完整的长期 -活资源。

*请注意，此处的“单个”资源可能由多个可能具有自己的 URI 的资源组成，因此拥有单个 DELETE 很容易。这会删除多个对象，但是如果删除 X 会删除 A、B 和 C，那么如果您没有 X 或者您的 API 将无法理解，那么显然您不能拥有 A、B 或 C。通常，这归结为正在建模的内容，以及一件事取决于另一件事的明显程度。

†严格来说我们可以，因为我们被允许发送缓存 header ，表明将相同的实体发送到相同的 URI 将产生相同的结果，但是没有通用的网络软件可以做到这一点，您的自定义客户端可以无论如何“记住”关于给定图像本身的意见。