纠正采用二进制数据的nullipotent操作的HTTP请求方法

Question

考虑一个没有副作用的Web API方法,但它将二进制数据作为参数.一个示例是一种方法,该方法告诉用户他们的图像是否被图片化,但是不会将图像或结果永久地存储在其服务器上.

这种方法应该是a GET还是POST？

GET似乎没有推荐的方法在URL参数之外发送数据,但该方法的行为意味着a GET,根据HTTP规范,这是为了安全,无状态响应.这在REST的语义下尤其受到限制,这意味着POST方法在服务器上创建了一个新对象.

Answer 1

这在 REST 语义下变得特别受限，这意味着 POST 方法在服务器上创建一个新对象。

虽然POST请求意味着发送的实体将被视为“由请求 URI 标识的资源的新从属”，但不要求这会导致创建新的永久对象或识别任何此类新对象通过 URI（因此，据客户端所知，没有新对象）。对象可以是暂时的，表示例如“向数据处理过程提供数据块，例如提交表单的结果”的结果，并且在表示该对象的实体被发送后不会持久化。

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

但是，您的直觉很希望这是一个GET：虽然POST手段的松散性我们可以为几乎每个请求提供一个案例（就像使用 HTTP 用于类似 RPC 的协议的方法所做的那样，基本上将 HTTP 视为好像它是一种传输协议），这在理论上是不优雅的，在实践中效率低下，定义上也很笨拙。您有一个幂等函数，它完全取决于客户端感兴趣的内容，并且最明显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 长度设置限制，实际上他们确实这样做了）。

可以像使用GETa 一样使用和发送请求正文POST，有些网络服务器甚至允许您这样做。但是，GET被定义为返回一个实体，该实体描述了 URI 中标识的资源，并带有限制该实体如何进行描述的标头：由于请求正文不是该定义的一部分，因此您的代码必须忽略它！如果您想改变这条规则，那么您必须考虑：

1. 有些网络服务器会拒绝请求或剥离正文，因此您可能无法这样做。
2. 如果您的网络服务器确实允许它，那么未指定的事实意味着您无法确定升级不会“修复”此问题，因此会破坏您的代码。
3. 一些代理会拒绝或取消请求。
4. 一些客户端库肯定会拒绝允许开发人员将请求正文与GET.

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

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

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

不，这里的所有方法都是POST将图像转换为固定 URI，然后返回一个描述分析的简单实体。

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

总而言之，虽然使 Web 应用程序远离 REST 的经典错误是滥用POST一切GET，PUT并且DELETE（可能还有 WebDAV 方法）会更胜一筹，但不要害怕使用它的强大功能满足要求，不要认为“资源的新下属”必须意味着一个完整的长期资源。

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

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