布尔REST结果的最佳实践

Question

我有一个资源

  /system/resource

我想问一下系统一个关于资源的布尔问题,这个问题无法通过客户端上的处理来回答(即我不能只获取资源并查看实际的资源数据 - 它需要在后端使用一些处理客户无法获得的数据).例如

  /system/resource/related/otherresourcename

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

我想到的可能性:

我不是特别想深入讨论RESTful系统的真正含义等等 - 我在标题中使用了REST这个词,因为它最好地表达了我正在设计的系统的一般风格(即使我可能正在抚育更多的是通过Web而不是真正的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会告诉它已完成.

为了帮助你更多,你必须更具体,详细的是你的"布尔问题"？什么是真正的资源和相关资源？

我可以想到两种可能性：1）在 /bob/friends 上执行 GET 并检查 john 是否是响应中的项目。或者更进一步，执行 GET /bob/friends/john，如果你得到 404 那么他们之间没有友谊，否则为 200。2) 将此信息直接包含到资源中： GET /bob，然后在 < human><name>bob</name><friends><friend>< human><name>john... 中搜索。如果 john 是响应的一部分，则存在关系，否则的话。从 Rest 的角度来看，我不会直接考虑服务器计算术语（这是 api 实现细节）。 (2认同)

Answer 2

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