虽然 SO 中有多个关于 RESTful API 中的命名约定的问题，但我找不到任何关于如何处理 bool 端点(返回 bool 值的端点)的引用。
考虑一个具有资源 /products 和 /orders 的 API。
一个订单可能引用多个产品，因此不可能在不弄乱相关订单的情况下删除一个产品。
在订单引用的产品中调用 DELETE/products/:id 将返回 409 Conflict。
到目前为止，一切都非常简单，但是如果客户想确认这个产品是否可以删除怎么办？
bool 端点将返回 true 或 false(或以某种方式包含此值的 JSON 结构)。
GET/products/:id/can-be-deleted
这里的问题是 can-be-deleted 不是(子)资源，它是检查某些内容的操作...
我觉得如果 RESTful API 应该使用名词并且端点中不应该有动词，那么它也不应该有形容词(/deletable、/completed)或谓词(/can-be-deleted, /is-ready).
如果是这样的话，这方面的约定是什么？
这些信息是否应该有自己的端点？
如果是这样，这个端点应该如何命名？
如果不是，此信息是否应该是另一个端点的一部分(类似于 GET/products/:id 返回此信息)？
最佳答案
Calling DELETE /products/:id in a product that is referenced by an order would return a 409 Conflict.
So far, everything is very straight forward, but what if the client wants to confirm if this one product can or cannot be deleted?
如果您正在尝试验证一个资源 可以是deleted :
OPTIONS /products/1
200 OK
Allow: GET, DELETE
Content-Length: 0
注意DELETE的语义属于transfer of documents over a network .
Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect. -- RFC-7231
在网络上，您如何知道是否可以提交表单？答案很简单:表格已提供给您。如果您没有获得表格(或链接)，则不允许您使用它。那是 uniform interface constraint :“超媒体作为应用程序状态的引擎。”
我们在表示中添加或删除元素以指示您可以通过应用程序采用的路径。作为客户，您检查以确保您的表示仍然是 fresh ;如果是，那么您可以选择发送请求。
The problem here is that can-be-deleted isn't a (sub)resource, it's an action to check something...
根本不是:这是关于某事的报告。
“检查某项操作”的一个典型示例是服务“健康检查”，我们使用这种检查来检测主机是否需要从负载均衡器中移除。
Any information that can be named can be a resource -- Fielding, 2000
机器不关心我们为资源使用什么标识符；因此，如果我们愿意，我们可以利用这种自由让人们的生活变得更轻松。通常，清楚地了解资源模型可以很容易地识别候选标识符；因此，当您在发现“足够好”的标识符时遇到困难时，我建议您更多地考虑模型。
关于api - 在 RESTful API 中处理 bool 端点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/67307880/