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

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

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

打开
.....
.....

使用ID有什么问题吗？例如，如果“open”是{1}

1.
.......
........

---

我想象您将有另一个url用于代码表以获取描述。类似于：

http://baseurl/codetables/orderstatus

&

http://baseurl/codetables/orderstatus/{id}

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

---

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

资源状态在示例中显示的两个XML有效负载中的描述或表示程度完全相同。与数字“1”相比，带有“open”一词的单词对人眼更友好，因此需要更少的解释。不过，我并不认为其中一种选择比另一种更能让人安心。因为可以说，即使是“开放”这个词也应该得到很好的解释。消费者应该能够理解开放状态的真正含义。从这一点开始，可能的状态转换是什么？等等等等

其次

http://baseurl/codetables/orderstatus/{id}

或

http://baseurl/codetables/orderstatus/open

与REST URL的观点并没有什么不同。但是要考虑的另一点是，你真的需要将属性引用表示为REST资源吗？好处是什么？对我来说，听起来像是WSDL世界中的模式定义

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