REST: Handling computed and related resource properties

This is a very common question when designing RESTful Services. And the best way I found to handling this is by documenting your RESTful Services correctly (maybe even provide a playground environment for the client to try out the apis). Here's how I will handle your usecase.

I will have a GET request for a given blog_post which will ONLY return the blog_post entity

GET /api/posts/abcd1234

which returns the basic blog_post with author id.

now, I will have a variation to the same GET request as this:

GET /api/posts/abcd1234?comments=true&authors=true&startIndex=0&offset=10&sortDirection=Ascending&sortBy=comment_date

The above api will return the post with author and the list of comments with authors with some other filters related to pagination etc. The client can use any permutation combination they like on this api filters and depending on the filter, you return the data back, something along the lines of

blog_post:{

your normal blog_post fields here ...

full author object here ...

comments: [{

list of comments (with author for each comment and applied filter) here ...

}]

}

This will also maintain your RESTful approach for other requests on the same blog_post. For example, updating the author of the blog_post

POST /api/posts/abcd1234

will still only update the authorId in the blog_post because the way you will document this POST request is just letting the client know that the only thing you expect here is a blog_post object with id, title, body an authorId and every other field that they might sent to you as a part of the blog_post request will be discarded/ignored.

How a client will consume your REST services, very heavily depends on how well have you documented your REST services.