Following on the heels of Guzzle, I’ve just read this piece on REST worst practices. As it happens, technology tends to be abused from time to time, REST included.
I’m far from a REST expert, so reading a piece like this helps to give me some context and guidance for the future. It looks like the comment thread in this piece is also worth perusing in an effort to further define the author’s advice.
Comments
There is an older RESTful Web Services book that outlines the points in this article very well. The author mentions that there is pure REST, and there is pragmatic REST, and as always – the truth tends to lie somewhere in the middle.
Building an API takes more thought process. I’ve been on teams where the API was ‘pure’ REST and extremely chatty. REST says that the consumer should never have to build URL’s on the other end, they should always be given a location endpoint (you could even have a potential base ‘phonebook’ that shows all available root calls). This chattiness takes it’s toll on performance, so other API’s have added enhancement and filter support to allow you to eager load other data with the request. This means a pure REST approach may take 40+ requests to render a ‘page’, whereas if you added in support for eager loading data, it could be cut down to much less requests (you are simply asking for more data in the payload – it’s a tradeoff).
I think the biggest takeaway for that article is the URL endpoints. Don’t pass back ID’s.
Nice to see Twitter chiming in with their experience, too.