布尔 REST 结果的最佳实践答案

【问题标题】：best practice for boolean REST results布尔 REST 结果的最佳实践
【发布时间】：2023-03-26 08:04:02
【问题描述】：

我有资源

  /system/resource

我想问系统一个关于资源的布尔问题通过在客户端处理来回答（即我不能只获取资源并查看实际的资源数据 - 它需要一些处理在后端使用客户端不可用的数据）。例如

  /system/resource/related/otherresourcename

我希望这是返回 true 或 false。有没有人有此类交互的最佳实践示例？

我想到的可能性：

使用 HTTP 状态码，没有返回正文（味道不对）
返回纯文本字符串 (True, False, 1, 0) - 不确定哪些字符串值适合使用，此外这似乎忽略了 Accept 媒体类型并总是返回纯文本
为我的每种支持媒体类型提供一个布尔对象并返回适当的类型（带有单个布尔值的 JSON 文档结果，具有单个布尔字段的 XML 文档）。但是，这似乎很笨拙。

我并不特别想就 a 的真正含义进行冗长的讨论 RESTful 系统等 - 我在标题中使用了 REST 这个词，因为它最能表达我正在设计的系统的总体风格（即使我我更倾向于通过 Web 进行 RPC，而不是真正的 REST）。然而，如果有人对真正的 RESTful 系统如何避免这个问题有一些想法我很乐意听到他们的声音。

【问题讨论】：

能否请您让标签更简单更具体？
是的，抱歉 - 真的不知道用什么来标记问题。我是专门用 MVC.NET 做的，但这个问题肯定适用于任何类似 REST 的系统？

标签： ruby-on-rails asp.net-mvc api rest

【解决方案1】：

嗯，很难回答（你的例子对我来说有点太抽象了）。

通常您可以将布尔信息设计为资源数据或专用资源。订单域示例，当您想知道订单是否完成时（布尔问题）。请注意，这是一个简化的示例（订单世界要复杂得多；）

将订单状态设计为数据负载

HTTP 调用： HTTP GET /orders

使用有效负载（json 格式）返回 200 OK： { id : "1" , completed : "true" }

将订单状态设计为资源

HTTP 调用： HTTP GET or HEAD /orders/completed/1

现在要获得“布尔”答案，您可以检查 HTTP 响应状态是 404 还是 200。400 表示订单尚未完成，200 表示已完成。

为了帮助您更多，您必须更具体，您的“布尔问题”具体是什么？什么是真正的资源和相关资源？

【讨论】：

Manuel，感谢您体贴的 cmets。想象一下，我们有一个资源“john”和另一个资源“bob”。这两者都具有诸如姓名、地址、出生日期、朋友列表等属性。因此它们都类似于“资源”，并且可以在宁静的架构中通过 GET 获取。然而，我想问一个关于这两种资源之间关系的布尔问题。实际的关系很简单（即我可以通过另一个人的朋友联系一个人），但显然涉及服务器端的一些计算。所以我想问HTTP GET /bob/isrelated/john
我可以想到两种可能性：1）在 /bob/friends 上执行 GET 并检查 john 是否是响应中的一个项目。或者更进一步，执行 GET /bob/friends/john，如果你得到 404，那么他们之间就没有友谊，否则 200。 2) 将此信息直接包含到资源中：GET /bob，然后在 bobjohn... 中搜索。如果 john 是响应的一部分，则存在关系，否则。从 Rest 的角度来看，我不会直接用服务器计算术语来思考（这是 api 实现细节）。
是的，我同意如果我的“关系”是可以表达的，我会将它们包含在资源中。我所说的涉及服务器计算的意思是，一个资源可能有数十万个相关资源（它是复杂网络的完全传递闭包）。所以关系是否存在依赖于无法发送到客户端的数据——它必须由服务器计算

【解决方案2】：

我认为返回 text/plain 将是最干净的选择。就接受标头而言，如果客户端确实无法处理纯文本，那么您可以恢复为 Json 或 Xml。
就个人而言，我会使用字符串“true”和“false”。大多数客户端语言都可以将这些字符串解析为适当的值。

【讨论】：

我同意他们不太可能无法处理文本计划，但在 API 的其余部分中，他们可以只使用他们想要的单一 Accept 类型 - 即在我的很多测试中使用 restclient 并将 Accept 设置为 application/json。在那种情况下，我真的必须返回包装的布尔 JSON，不是吗？
是的，根据http://tools.ietf.org/html/rfc2616#section-14.1，如果您的客户没有说它支持文本/纯文本，那么您不应该发送它。