布尔REST结果的最佳实践

Question

我有资源

  /system/resource

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

  /system/resource/related/otherresourcename

我希望这是返回true或false。有没有人有 这种互动的最佳实践范例？

我想到的可能性：

• 使用HTTP状态代码，没有返回正文（闻起来有误）

• 返回纯文本字符串（True，False，1,0） - 不确定哪些字符串值适合使用，此外 这似乎忽略了Accept媒体类型并且总是返回 纯文本

• 为我的每种支持媒体类型提供一个布尔对象 并返回适当的类型（带有单个布尔值的JSON文档 结果，一个带有单个布尔字段的XML文档）。然而，这似乎很笨拙。

我并不特别想深入讨论a的真正含义 RESTful系统等 - 我在标题中使用了REST这个词，因为它 最好的表达我正在设计的系统的一般风味（即使也许我 我更倾向于通过网络而不是真正的REST）。但是，如果 有人对真正的RESTful系统如何避免这个问题有一些想法 完全我会很高兴听到他们。

Answer 1

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

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

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

HTTP电话： HTTP GET /orders

会给你带200有效负载（json格式）： { id : "1" , completed : "true" }

将订单状态设计为资源

HTTP电话： HTTP GET or HEAD /orders/completed/1

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

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

Answer 2

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