在 RESTful API 中处理布尔端点

Question

尽管 SO 中有多个关于 RESTful API 中的命名约定的问题，但我找不到任何有关如何处理布尔端点（返回布尔值的端点）的参考。

考虑一个具有资源

/products

和

/orders

的 API。
一个订单可能引用多个产品，因此不可能在不弄乱相关订单的情况下删除产品。
在订单引用的产品中调用

DELETE /products/:id

将返回

409 Conflict

。

到目前为止，一切都非常简单，但是如果客户想确认该产品是否可以删除怎么办？

布尔端点将返回 true 或 false（或以某种方式包含此值的 JSON 结构）。

GET /products/:id/can-be-deleted

这里的问题是

can-be-deleted

不是（子）资源，它是检查某些内容的操作...
我觉得如果 RESTful API 应该使用名词并且端点中不应该有动词，那么它也不应该有形容词 (

/deletable

,

/completed

) 或谓词 (

/can-be-deleted

,

/is-ready

)。

如果是这样的话，这方面的约定是什么？
这些信息应该有自己的端点吗？
如果是这样，这个端点应该如何命名？
如果不是，此信息是否应该是另一个端点的一部分（例如

GET /products/:id

返回此信息）？

Answer 1

在订单引用的产品中调用 DELETE /products/:id 将返回 409 冲突。

到目前为止，一切都非常简单，但是如果客户想确认该产品是否可以删除怎么办？

如果您尝试验证资源是否可以删除：

OPTIONS /products/1

200 OK
Allow: GET, DELETE
Content-Length: 0

请注意，DELETE 的语义属于通过网络传输文档。

允许使用 DELETE 方法的资源相对较少——它的主要用途是远程创作环境，用户对其效果有一定的指导。 -- RFC-7231

在网络上，您如何知道是否可以提交表单？答案很简单：表格已提供给您。如果您没有获得表单（或链接），则您无权使用它。这就是统一接口约束：“超媒体作为应用程序状态的引擎。”

我们从表示中添加或删除元素来指示您可以通过应用程序采取的路径。作为客户，您需要检查以确保您的陈述仍然是新鲜；如果是这样，那么您可以选择发送请求。

这里的问题是 can-be-deleted 不是（子）资源，而是检查某些内容的操作...

一点也不：这是一篇关于某事的报告。

“检查某些内容的操作”的一个典型示例是服务“运行状况检查”，我们用这种方法来检测是否需要从负载均衡器中删除主机。

任何可以命名的信息都可以是资源 -- Fielding, 2000

机器不关心我们对资源使用什么标识符；因此，如果我们愿意的话，我们可以利用这种自由让人们的生活变得更轻松。通常，清楚地了解资源模型可以轻松识别候选标识符；因此，当您在发现“足够好”标识符时遇到困难时，我建议您更多地考虑模型。

Answer 2

建议：

PS：

如果您还没有这样做，我鼓励您（重新）阅读 Roy Fielding 的原始论文：