0

What i've read on REST it seems like they always use descriptions rather than IDs when returning REST responses. For example:

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

Anything wrong with using IDs? For example if "open" was {1}

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

I image you would have another url for your code tables to get the descriptions. Something like: http://baseurl/codetables/orderstatus & http://baseurl/codetables/orderstatus/{id}

4

2 回答 2

1

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

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

于 2012-05-26T14:11:43.267 回答
0

The resource state is described or represented exactly to the same extent in both the XML payloads you have shown in the examples. One with the word 'open' is more friendly to human eye compared to number '1', hence requiring less explanation. Still I do not think one is more RESTful than the other option. Because arguably even the word 'open' should be well explained. The consumer should be able to understand what really is meant by open state. What are the possible state transitions from that point on? etc. etc.

Secondly http://baseurl/codetables/orderstatus/{id} or http://baseurl/codetables/orderstatus/open are not really different from REST URL point of view. But another point to consider is that do you really need to represent attribute references as REST resources? What is the benefit? Sounds like equivalent of schema definitions in the WSDL world to me.

于 2014-06-03T10:42:19.947 回答