http - REST 问题 : PUT one representation, 换一个？

Question

问题的简短版本:
特定 URI 的“GET”是否需要与该 URI 的“PUT”相匹配？

我认为不是。原因如下:

鉴于资源是客户端理论上不可知的抽象事物，当我们进行 PUT 时，我们必须只发送表示。基于对 RFC2616 的梳理，对于具有许多(可能是无限的？)表示的资源意味着什么似乎并没有完全指定，但这是我的想法；如果您同意，请告诉我:

我的期望是，如果我 PUT 一个资源的表示，该 URI 处资源的所有其他表示都应根据需要保持一致(可能会更新)。换句话说，您是在告诉资源“使用此表示重新定义您自己”。

因此，我应该能够做到这一点:

PUT /resources/foo/myvacation
Content-type: image/jpg
...

然后跟进:

GET /resources/foo/myvacation
Accept: image/png
...

并以不同的格式获取更新版本的 myvacation(假设服务器知道如何执行此操作)。由此推断，这个复合原子“图像 + 元数据”PUT 也应该是合法的:

PUT /resources/foo/myvacation
Content-type: multipart/form-data

Content-disposition: form-data; name="document"
Content-type: image/jpg
[..]
Content-disposition: form-data; name="iptc"
Content-type: application/iptc
[..]
Content-disposition: form-data; name="exif"
Content-type: application/exif
[..]

然后，由于服务器端内容协商(RFC2616 第 12.1 节)几乎可以基于任何内容进行，因此我们可以为此默认使用“文档”内容:

GET /resources/foo/myvacation
Content-type: image/jpg
[..]

或者如果您像我一样相信 RFC 2396 第 3.4 节“查询组件是要由资源解释的信息字符串。”意味着带有查询字符串的 URI 与没有查询字符串的 URI 引用相同的资源(并且是同构的，只是将 application/x-form-urlencoded 数据发送到资源)，那么这也应该是合法的:

GET /resources/foo/myvacation?content=exif
Content-type: application/exif
[..]

PUT 的描述说:

PUT 方法请求将封闭的实体存储在提供的 Request-URI 下。

对我来说，这是相当反 REST 的，除非你以一种非常自由的方式阅读它。我的解释是“PUT 方法请求根据所包含实体的表示在提供的 Request-URI 处创建或更新资源。”

稍后，我们得到:

POST 和 PUT 请求之间的根本区别反射(reflect)在 Request-URI 的不同含义上。 POST 请求中的 URI 标识将处理封闭实体的资源。该资源可能是一个数据接受进程、某个其他协议(protocol)的网关或一个接受注释的独立实体。相反，PUT 请求中的 URI 标识包含在请求中的实体——用户代理知道 URI 是什么，服务器不得尝试将请求应用于其他资源。

我们需要类似地创造性地阅读它，但这里的关键是“知道 URI 的目的”和“应用请求”。

因此，对我来说，在给定 URI 处由 GET 返回的表示不一定与 PUT 到给定 URI 的表示相同，它只需要保持一致即可。

对还是错？

Answer 1

基于内容协商可以从同一 URI 返回不同表示的事实，我很确定您 PUT 的内容不必与您检索的内容相同。