This book is very good: http://www.amazon.com/RESTful-Web-APIs-Leonard-Richardson/dp...

Classic: http://www.slideshare.net/guestbe92f4/how-to-design-a-good-a...

RESTful Web APIs (http://shop.oreilly.com/product/0636920028468.do) was a good starting point for understanding RESTful HTTP APIs.

I think REST is orthogonal to relational data. (Actual REST, that adheres to HATEOAS and a real REST standard. If one rolls his own JSON services, it's not REST.) HATEOAS puts no constraint on how your data is shaped. A specific implementation of REST may or may not have a nice way to navigate graphs.

[0] http://restcookbook.com/Basics/hateoas/

RESTful Web APIs (2013)[1] is a very, very good book about this stuff. The book has a mailing list with some good discussion about this stuff [2].

[1] http://www.amazon.com/RESTful-Web-APIs-Leonard-Richardson/dp... [2] https://groups.google.com/forum/?fromgroups=#!searchin/colle...

I'm still exploring this stuff myself so maybe I am wrong or misunderstanding you.

Neither is more (or less) ReSTful than the other.

If you think that consumers of the API would like to see the orders, embed them.

If you think that consumers would like to see an attribute like `total` for the order, embed it.

If you think that consumers would like to see some user_account information, embed it.

If you think that the total size of a collection is too big, paginate.

Tell your users that `X` may be embedded in `Y` and `Y` may be embedded in `Z`.

Write the code that consumes the API to expect the API to change.

HEATEOS is the constraint that matters in REST, all else is provided by the http spec etc.

If you want to paginate, use link realtions: http://www.iana.org/assignments/link-relations/link-relation...

If you want to describe a relationship, use a link relation.

Watch this: http://vimeo.com/20781278 Read this: http://shop.oreilly.com/product/0636920028468.do