Reputation: 24583
I am having a hard time wrapping my head around how to model a child resource.
Take the example of books with an author. You can have N books each with only one author.
/books GET
/books POST
/books/id PUT
/books/id DELETE
So far easy.
What about adding an author to a book. Removed at least for this example each book only has one author
/books/id/author POST
That seems confusing to me as POST usually means create. In the case where an author is already set the user of the api migh think they are just creating a new author when in fact they are deleting the old author and replacing it with a new author.
That leaves me with
/books/id/author PUT
meaning update the author resource for that book. Makes a little more sense. But what about the first time when no author exist? Not really an update but the initial create? Maybe just thinking about it is update a nil author.
Should this even be a child resource? It's going to be a complex object so kind of makes sense. Although I guess you can't have a book without an author. So should I not model as child resource and say that you pass the author object when you create or modify the book resource.
Final thought. I don't think I will model authors as a root resource. So at least in this case they will only ever exist under a book resource. And again only one author per book.
Upvotes: 1
Views: 681
Reputation:
But what about the first time when no author exist? Not really an update but the initial create?
Using PUT /books/id/author
to initially create the author looks fine to me. As you can use PUT /books/client-supplied-id
to create a book with an ID supplied by the client, you can create the author of a book which is identified by the known path segment author
.
Since you write that an author will only exist as a component of a book, this URL scheme is fine.
Upvotes: 2