Reputation: 8199
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}
Upvotes: 0
Views: 83
Reputation: 2978
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.
Upvotes: 0
Reputation: 35445
Generally the IDs are only for the database to keep it normalized and to provide uniqueness. So it is rare to need a REST API that would expose the ID. So you may want to recheck the design as to why this need is arising.
That said, if your use case is different and the ID is actually something that needs to be outside, then I don't see any problem with REST APIs returning IDs.
Upvotes: 1