更确切地说:
根据休息样式,通常认为POST,GET,PUT和DELETE http方法应该用于CREATE,READ,UPDATE和DELETE(CRUD)操作.
事实上,如果我们坚持使用http方法定义,事情可能就不那么清楚了
在本文中,它解释了:
简而言之:当且仅当您知道资源所在的URL以及资源的全部内容时才使用PUT.否则,请使用POST.
主要是因为
PUT是一个限制性更强的动词.它需要一个完整的资源并将其存储在给定的URL中.如果之前有资源,则将其替换; 如果没有,则创建一个新的.这些属性支持幂等性,天真的创建或更新操作可能不支持.我怀疑这可能是为什么PUT的定义方式; 它是一种幂等操作,允许客户端向服务器发送信息.
在我的情况下,我通常会发布传递所有资源数据的更新,因此我可以使用PUT进行更新,但每次发出更新时,我都会保存一个LastUser和LastUpdate列,其中包含进行修改的用户ID和操作的时间.
所以我想知道你的意见,因为严格来说,这两列并不是资源的一部分,但它们确实阻止了操作是幂等的.
saludos
SAS
这里的一些开发人员正在讨论关于来自RESTful API的GET请求是否应该返回所请求资源的ID的友好(有些人会说是宗教性的).我们假设以下GET请求:
http://my.api.com/rest/users/23
目前返回:
{"name": "Jim", "age": 40, "favoriteColor": "blue"}
请注意,结果集中缺少"id".
基本上有4个阵营与这个问题作斗争.
CAMP#1:当呼叫者发出GET请求时,他们已经知道了ID.因此,结果集应该不包括ID.如果调用者需要此数据来启用UI编辑,则调用者需要通过ID 23,可能手动将成员{"id":23}添加到JSON.
Camp#1中的人员也认为结果集中ID的存在表明该值可以被修改,当然它不能.
CAMP#2:没有ID,JSON结果集本身不能用于UI表单中的编辑/更新操作.相反,AJAX回调机制需要负责传递ID字段并手动将这些字段添加到结果集中.这似乎很笨拙且容易出错.UI人员正在争论结果集"感觉"就像缺少应该存在的数据,即ID.
营地#3:这些人关心的是一致性.如果我们有API返回的用户对象集合,这些对象必须包含ID.因此,为了保持一致性,GET的单例版本还应包含ID.
CAMP#4:这些人建议用户的GET请求可以返回包含ID的HyperMedia或SelfLinks形式的元数据.
这不是一个深奥的"谁是对的？" 争论,或者.我们采用的方法将决定API的形状,并影响几个开发人员在新的几周内的工作量.
作为其他人（例如：here），我正在为这个问题苦苦挣扎，GET和PUT的表示是否应该相同？
例子：
GET 表示：
{
"id": "0815",
"name": "jdoe",
"emailAddress": "jd@example.com",
"displayName": "John Doe",
"active": true
}
PUT 表示：
{
"emailAddress": "jd@example.com",
"displayName": "John Doe"
}
研究：
我在REST 问题中读到：PUT one representation, GET a different one？没关系，用 GET 获取另一种媒体类型，就像我用 PUT 保存的一样。
我在REST 中阅读- 是否将 ID 放入正文？没关系，用 PUT 省略 id 并用 GET 获取 id。
我在GET Representation != POST Representation中读到，用 PUT 省略很多属性并用 GET 获取它们是可以的。一个例子是JIRA REST API - …