问题简述:
在特定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-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
[..]
然后,因为服务器端内容协商(RFC2616第12.1节)可以基于几乎任何东西进行,我们可以为此使用“document”内容的默认值:
GET /resources/foo/myvacation
Content-type: image/jpg
[..]
或者如果您像我一样相信RFC 2396第3.4节“查询组件是要由资源解释的信息字符串。”,则具有查询字符串的URI指向与不具有查询字符串的URI相同的资源,而且是与仅发送应用程序/x-form-urlencoded数据到资源等价的,则这也应该是合法的:
GET /resources/foo/myvacation?content=exif
Content-type: application/exif
[..]
PUT的说明如下:
PUT方法请求将封闭的实体存储在提供的请求URI下。
对我而言,这相当违反REST原则,除非你以非常自由的方式阅读它。我的解释是:“PUT方法请求基于所包含实体的表示,在提供的Request-URI处创建或更新资源。”稍后我们得到以下内容:
“POST和PUT请求之间的根本区别反映在Request-URI的不同含义上。 POST请求中的URI标识将处理所包含实体的资源。该资源可能是接受数据的进程,其他协议的网关或接受注释的单独实体。相比之下,PUT请求中的URI标识了请求所附带的实体 - 用户代理知道预期的URI,服务器不得尝试将请求应用于其他资源。”
我们需要以类似的创造性方式阅读这个内容,但关键点在于“知道预期的URI”和“应用请求”。
因此,对我来说,在给定URI处通过GET返回的表示不一定与放置到给定URI的表示相同,它只需要是一致的。
正确还是错误?