REST问题：PUT一个表示，获得一个不同的表示？ [英] REST question: PUT one representation, GET a different one?
问题描述
问题的简短版本：
特定URI的GET是否需要与PUT匹配到该URI？
我想不是。原因如下：
鉴于资源是客户理论上不可知的抽象事物，当我们进行PUT时，我们必须只发送一个表示。基于对RFC2616的梳理，对于具有许多（可能是无限的？）表示的资源来说，它似乎没有完全具体说明，但这是我的想法;如果您同意，请告诉我：
我的期望是，如果我将表示形式提供给资源，那么该URI上资源的所有其他表示应保持一致（可能必要时更新）。换句话说，您告诉资源使用此表示来重新定义自己。
因此，我应该可以这样做：
PUT /资源/ foo / myvacation
内容类型：image / jpg
...
并跟进：
GET / resources / foo / myvacation
接受：image / png
...
并以不同的格式获取myvacation的更新版本（假设服务器知道如何操作）那）。从中推断，这个复合原子图像+元数据PUT也应该是合法的：
PUT / resources / foo / myvacation
内容类型：multipart / form-data
内容处理：表单数据; name =document
内容类型：image / jpg
[..]
Content-disposition：form-data; name =iptc
内容类型：application / iptc
[..]
Content-disposition：form-data; name =exif
内容类型：application / exif
[..]
然后，因为服务器端内容协商（RFC2616第12.1节）可以基于任何事情进行，我们可以默认为文档内容：
GET / resources / foo / myvacation
内容类型：image / jpg
[..]
或者如果你像我一样认为RFC 2396第3.4节查询组件是由资源解释的一串信息。意味着带有查询字符串的URI引用与没有查询字符串的URI相同的资源（并且只是将application / x-form-urlencoded数据发送到资源是同构的），那么这也应该是合法的：
GET / resources / foo / myvacation？content = exif
内容类型：application / exif
[..]
PUT的描述说：
PUT方法请求将所包含的实体存储在提供的Request-URI下。
对我来说，这是相当反REST的，除非你以非常自由的方式阅读它。我的解释是PUT方法根据所包含实体的表示请求在提供的Request-URI处创建或更新资源。
稍后，我们get：
POST和PUT请求之间的根本区别体现在Request-URI的不同含义上。 POST请求中的URI标识将处理所包含实体的资源。该资源可能是数据接受过程，某些其他协议的网关或接受注释的单独实体。相反，PUT请求中的URI标识请求附带的实体 - 用户代理知道URI的用途，并且服务器不得尝试将请求应用于其他资源。
我们需要同样创造性地阅读这一点，但这里的关键部分是知道什么是URI和应用请求。
所以，对我来说，GET在给定URI处返回的表示不一定必须与PUT到给定URI的表示相同，它只需要保持一致。 / p>
是或否？
基于内容协商的事实可以从同一个URI返回不同的表示形式，我很确定你的PUT不必与你检索的内容相同。
Short version of the question:
Does "GET" at a particular URI need to match what was "PUT" to that URI?
I think not. Here's why:
Given that a resource is an abstract thing that is theoretically unknowable by the client, when we do a PUT, we must be only sending a representation. Based on combing over RFC2616, it doesn't seem entirely specified as to what that means for a resource that has many (potentially infinite?) representations, but here are my thoughts; please tell me if you agree:
My expectation is that if I PUT a representation to a resource, all other representations of the resource at that URI should be kept consistent (potentially updated) as necessary. In other words, you're telling the resource "use this representation to redefine yourself".
Thus, I should be able to do this:
PUT /resources/foo/myvacation
Content-type: image/jpg
...
And follow up with this:
GET /resources/foo/myvacation
Accept: image/png
...
and get the updated version of myvacation in a different format (assuming the server knows how to do that). Extrapolating from that, this composite atomic "image + metadata" PUT should also be legal:
PUT /resources/foo/myvacation
Content-type: multipart/form-dataContent-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
[..]
And then, because server-side content negotiation (RFC2616 section 12.1) can take place based on just about anything, we can default to the "document" content for this:
GET /resources/foo/myvacation
Content-type: image/jpg
[..]
or if you believe as I do that RFC 2396 section 3.4 "The query component is a string of information to be interpreted by the resource." means that a URI with a query string refers to the same resource as a URI without a query string (and is isomorphic with just sending application/x-form-urlencoded data to the resource), then this should also be legal:
GET /resources/foo/myvacation?content=exif
Content-type: application/exif
[..]
The description of PUT says:
The PUT method requests that the enclosed entity be stored under the supplied Request-URI.
To me, this is fairly anti-REST, unless you read it in a very liberal manner. My interpretation is "The PUT method requests that a resource be created or updated at the supplied Request-URI based on the representation of the enclosed entity."
Later on, we get:
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.
We need to similarly read this creatively, but the key bits here are "knows what URI is intended" and "apply the request".
So, to me the representation returned by GET at a given URI does not necessarily have to be the same representation that was PUT to the given URI, it just has to be consistent.
True or false?
Based on the fact that content negotiation can return different representations from the same URI, I am quite sure that what you PUT does not have to be the same as what you retrieve.
这篇关于REST问题：PUT一个表示，获得一个不同的表示？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
