替换资源的状态

REST与协议无关，是resource-oriented架构。例如，通过HTTP协议实现REST应用程序时，资源由URI标识，资源上的操作由HTTP method表示。

PUT是用于替换资源状态的HTTP方法，资源的新状态将使用例如JSON和/或XML在请求有效负载中表示。

因此，您可以考虑以下设计来启动/停止数据库：

PUT /databases/:id/status HTTP/1.1
Content-Type: application/json

{
    "value": "started"
}

PUT /databases/:id/status HTTP/1.1
Content-Type: application/json

{
    "value": "stopped"
}

要获取资源的状态，请使用GET：

GET /databases/:id/status HTTP/1.1

响应状态代码

您当然需要告知您的客户有关操作的结果。为此，请使用HTTP response status codes。

一些可能有用的状态：

200：使用此状态表示请求已成功。
202：使用此状态代码表示已接受处理请求，但处理尚未完成。
204：使用此状态代码表示服务器已成功完成请求，并且没有其他内容可在响应有效负载正文中发送。
409：使用此表示由于与目标资源的当前状态冲突而无法完成请求。

Answer 2

Jim Webber解释说＆＃34; HTTP是传输文档的应用程序协议＆＃34;应用程序中状态的转换是文档传输触发的副作用。

想想旧式纸张驱动的商务办公室：老板出现并在收件箱中删除TODO消息，其中说“停止数据库＆＃34;”。作为副作用，您可以旋转椅子并启动清洁关闭程序。

因此，惯用语是，您发送到REST服务器的表示形式是TODO消息的表示形式，并且您要将其发送给（a）代表＆＃34;收件箱的资源＆＃34; - 即，TODO消息的特定集合 - 或（b）代表TODO文档本身的资源。

我有一个可以用来控制数据库的REST服务，我想允许调用Stop＆amp;启动数据库，但想知道什么是正确的方法？

通过调用Stop或Start Operation我正在改变资源的状态，所以PUT似乎是正确的，但PATCH更好甚至是POST？

由于您发送的是完整的消息，而不是尝试修改REST服务器已经知道的消息，因此PATCH不合适。

DELETE也不合适 - 删除类似于销毁收件箱中的TODO消息。

如果您用来表示客户端的应用程序状态的媒体类型是HTML，那么您使用的动词将 POST，因为HTML doesn't support PUT。

如果要向表示集合的资源提供单个消息的表示，那么您使用的动词将 POST，因为PUT的语义意味着＆＃34;创建/覆盖＆＃34;一个资源，你正在表达的语义是附加的。

如果要将单个消息的表示提供给仅表示该消息的资源（即：您正在创建消息资源），则PUT优先于POST。这里的关键思想是PUT承诺服务器上的任何副作用都是幂等 - 成功传递N＆gt;的副作用。 0份邮件副本相当于传送1份副本的副作用。使用PUT作为动词共享，承诺，不仅是客户端和服务器，还包括所有中间连接器。

您的幂等资源也可以支持POST，您可以在API中记录收到的消息是否得到了理论上的处理，以便客户能够理解，但是没有标准化的方法来告知其他连接器这一事实。 / p>

（例如：考虑一下浏览器中的表单帖子。服务器上的资源知道请求可以被幂等地处理。你可以在html本身中记录多次点击按钮是安全的，但你不要＆＃ 39;有任何办法告诉浏览器，所以浏览器会向用户发出一条消息说“重新发布可能不安全，你确定Y / N吗？＆＃34;）

总之，您希望您对HTTP方法的选择与统一接口一致，以便客户端，服务器以及作用于其间消息的所有组件都有共同的理解发生了什么事。

PUT，POST或PATCH？

2 个答案:

替换资源的状态

响应状态代码