处理数据库代码表时的基本 REST 设计

Question

我在 REST 上读到的内容似乎在返回 REST 响应时总是使用描述而不是 ID。例如：

<order>
    <orderstatus>
        open
     </orderstatus>
     .....
     .....
</order>

使用 ID 有什么问题吗？例如，如果{1}"打开"

<order>
     <orderstatus>
        1
     </orderstatus>
     .......
     ........
</order>

我想你会有另一个 url 来获取描述的代码表。像这样：http://baseurl/codetables/orderstatus和http://baseurl/codetables/orderstatus/{id}

Answer 1

通常，ID 仅用于数据库，以保持其规范化并提供唯一性。因此，很少需要公开 ID 的 REST API。因此，您可能需要重新检查设计，以了解为什么会出现这种需求。

也就是说，如果您的用例不同并且 ID 实际上是需要在外部的东西，那么我认为 REST API 返回 ID 没有任何问题。

Answer 2

资源状态在示例中所示的两个 XML 有效负载中以完全相同的程度描述或表示。与数字"1"相比，带有"开放"一词的人对人眼更友好，因此需要较少的解释。我仍然不认为一个比另一个选项更令人不安。因为可以说，即使是"开放"这个词也应该得到很好的解释。 消费者应该能够理解开放状态的真正含义。从那时起，可能的状态转换是什么？等等。

其次 http://baseurl/codetables/orderstatus/{id}或http://baseurl/codetables/orderstatus/open与 REST URL 的观点并没有真正的区别。 但要考虑的另一点是，你真的需要将属性引用表示为 REST 资源吗？有什么好处？ 对我来说，这听起来相当于 WSDL 世界中的模式定义。