Question

我的团队正在构建一个REST API，其中有一个特定名词有4个状态。就我而言，它是Claim。客户会向Open / Update / Close / Re-Open声明发送请求。

我们为这些请求提供了不同的请求/响应JSON模式

据我所知，谷歌搜索并采取了建议，这对add verbs to your API URLs来说是一种不好的做法。

场景1 ::我发布了一个POST href = "/claim"

此处客户端会在Claim Status请求POST中发送Header，我会解析，转换然后验证（基于JSONSchema）JSON } POJO取决于声明状态是什么。

场景2 ::我创建4 multiple service endpoints，将这些状态视为Nouns instead of Verbs，因为要求只是那样。

示例：href = "/claim/open" "/claim/update等

我想选择#2，因为#1似乎非常乏味和不整洁。

另外，#2我不确定我是否遵守惯例。

情景#3 还有一位同事想到我们可以提出类似的请求 POST /claim身体中有4个状态，如

{
  'open' : {openJSON},
  'update' : {updateJSON},
  'close' : {closeJSON},
  'reopen' : {reopenJSON},
}

无论状态如何，JSON的那部分都将由客户发送。

Answer 1

在URI中不使用动词的做法基于URI识别资源的概念。但是，URI完全有效，用于标识对资源执行某些操作的脚本。该资源可以通过POST方法执行。

从技术上讲，您可以用这种方式编写整个API，但如果只使用HTTP方法，那么它就更好了。我就是这样做的。

打开声明

POST /claims

在/claim/1234处创建声明资源，其中1234是声明编号。

更新声明

PUT /claim/1234或PATCH /claim/1234

本质上，客户端以/claim/1234的副本开头，进行所需的更新并将新状态发送回服务器。

关闭声明

POST /claim/1234/close

我不认为DELETE在这种情况下是合适的，因为您不希望声明消失，您只是将其标记为已关闭。我希望/claim/1234有一个状态字段，指示它是打开还是关闭。从技术上讲，您可以只更新该状态，根本不需要此调用，但对于非常具体的更新，我希望有一个专用端点。我认为它可以更好地传达意图。

重新开启声明

POST /claim/1234/reopen

同样，这是一个非常具体的更新，我认为它应该以表达意图的名义拥有自己的资源，但它并非绝对必要。此外，如果您想要避免使用动词，请始终将其称为/claim/1234/reopener。可以说，这更有效地表明这是一种可以用来重新开启索赔的资源。