3

所以这里是这个方法现在的样子：

POST person/personId/edit
https://api.example.com/*key*/person/*personId*/edit?FName=Blah

我希望这将 personId 中的人的名字更改为 Blah。

如果我需要添加一个人，我会说：

PUT person/create
https://api.example.com/*key*/person/create

它将添加一个具有新 personId 的人。

4

2 回答 2

4

一般约定通常是：

GET    => READ
POST   => CREATE
DELETE => DELETE
PUT    => UPDATE

我可以看到的一个区别是您还使用了不同的 URI，最常用的是单个资源 URI。但是，无论如何，这是有争议的，所以这是你喜欢它的问题。

于 2012-06-18T18:05:32.837 回答
3

我对 POST 和 PUT 的解释一直是：

POST - 服务器将收到一个实体，它可以用来执行操作或创建资源。如果端点的意图是创建一个资源，那么 POST 将始终创建一个 NEW 资源。在任何情况下，每个 POST 都会被处理而不考虑资源的状态。您只是将信息发布到服务器以供其操作。

例子：

  • 想象一个将向用户手机发送消息的 Web 服务。POST 可用于向服务器提供可能不适合 GET 的必要信息。请求有效负载将包含此信息。服务器上没有创建资源，所以操作返回200 OK，表示操作成功完成。该响应还可以包括一个正文，该正文包含来自服务器操作的信息。
  • 想象一个 Web 服务，它创建一张张贴在公告板上的票。POST 可以包含发布该帖子所需的信息。信息保存在服务器上并返回 201 Created（可能是包含用户 ID 的响应正文，或者创建后产生的更完整的对象）。在所有情况下，当将某些内容发布到此端点时，都会创建一个新票证。

PUT - 服务器将接收一个实体（例如，带有一个 ID），目的是创建或替换一个资源。如果资源已经存在，则将其替换为请求中的资源，否则将创建一个新资源。在所有情况下，服务器上都会保留一些内容。必须提供某种唯一标识实体的方法。换句话说，客户端是创建 ID 的人，因为如果需要创建实体，将使用它。我认识的大多数人都在与这个现实斗争。

例子：

  • Web 服务从客户端接收包含用户信息的有效负载。期望是用户将被保存。服务器将检查该用户是否存在。如果是这样，它将通过将其（全部）替换为请求提供的新资源来更新该用户，并返回 200 OK 或 204 No Content。如果它不存在，它将创建它并返回 201 Created。
于 2013-05-31T20:06:17.103 回答