我有资源
/system/resource
我希望系统问一个关于资源的布尔问题 通过客户端处理来回答（即我不能只获取资源 并查看实际的资源数据 - 它需要一些处理 在后端使用客户端无法获得的数据）。例如
/system/resource/related/otherresourcename
我希望这是返回true或false。有没有人有 这种互动的最佳实践范例？
我想到的可能性：
使用HTTP状态代码，没有返回正文（闻起来有误）
返回纯文本字符串（True，False，1,0） - 不确定哪些字符串值适合使用，此外 这似乎忽略了Accept媒体类型并且总是返回 纯文本
为我的每种支持媒体类型提供一个布尔对象 并返回适当的类型（带有单个布尔值的JSON文档 结果，一个带有单个布尔字段的XML文档）。然而，这似乎很笨拙。
我并不特别想深入讨论a的真正含义 RESTful系统等 - 我在标题中使用了REST这个词，因为它 最好的表达我正在设计的系统的一般风味（即使也许我 我更倾向于通过网络而不是真正的REST）。但是，如果 有人对真正的RESTful系统如何避免这个问题有一些想法 完全我会很高兴听到他们。
答案 0 :(得分：5)
通常，您可以将此类布尔信息设计为资源数据或专用资源。当您想知道订单是否完成时（布尔问题），订单域的示例。请注意这是简化的例子（订单世界要复杂得多;）
将订单状态设计为数据有效负载
HTTP电话：
HTTP GET /orders
会给你带200有效负载（json格式）：
{ id : "1" , completed : "true" }
将订单状态设计为资源
HTTP电话：
HTTP GET or HEAD /orders/completed/1
现在要获得“布尔”答案，您可以检查HTTP响应状态是404还是200. 400会告诉订单尚未完成，200会告诉它已完成。
为了帮助你，你必须更加具体，你的“布尔问题”是什么？什么是真正的资源和相关资源？
答案 1 :(得分：3)
我认为返回text / plain将是最干净的选择。就接受头而言，如果客户端真的无法处理文本plain，那么你可以恢复为Json或Xml。
就个人而言，我会使用字符串“true”和“false”。大多数客户端语言都可以将这些字符串解析为适当的值。