REST and links: middle ground?
Posted
by
pbean
on Stack Overflow
See other posts from Stack Overflow
or by pbean
Published on 2012-09-17T21:17:42Z
Indexed on
2012/09/17
21:38 UTC
Read the original article
Hit count: 211
I've been wondering about how far to go with links in REST. Consider books which have authors, but there is obviously a many-to-many relationship between books an authors (a book can be written by multiple authors, and authors can write multiple books).
So let's say we have a rest call http://server/book/21
, which will return a book XML, containing information about an author. Now since the book is a resource, and the author is a resource, the XML should not straight up include all the author information. It should contain a link to the author information. But which of the below two examples is more widely accepted?
(Excuse my crappy formatted XML, I am not that experienced with hand writing XML)
<book>
<title>Some Book</title>
<authors>
<author link="http://server/author/82">Some Guy</author>
<author link="http://server/author/51">Some Other Guy</author>
</authors>
</book>
Then, an author link would return more information:
<author>
<name>Some Guy</name>
<dateOfBirth>some time</dateOfBirth>
</author>
Or:
<book>
<title>Some Book</title>
<authors>http://server/book/21/authors</authors>
</book>
Where http://server/book/21/authors
returns:
<authors>
<author link="http://server/author/82">Some Guy</author>
<author link="http://server/author/51">Some Other Guy</author>
</authors>
And then each of those returns the former <author>
example again.
The reason I'm asking is basically because at my job they went with the second approach, and it seems to me that clients have to take many more steps to reach where they want to go. Also, for basic information which "you're always going to need" (author's name), you do have to take one additional step.
On the other hand, that way the book
resource only returns information about the book (nothing else), and to get anything else, you have to access other resources.
© Stack Overflow or respective owner