At the end of his article the author says, 'Now you don't have any excuses.' I respectfully beg to differ. I think the 'proper' way of doing things he describes

At the end of his article the author says, 'Now you don't have any excuses.' I respectfully beg to differ. I think the 'proper' way of doing things he describes is much more work for the clients of the API. The benefits to the clients he describes, such as not being mercy to changes in the API's URL structure, are indeed benefits, but they're not guaranteed to be realized, and it's questionable whether they would pay for the extra work required. Implementing the API as described would allow clients to create client apps more tolerant to changes in the API, but the additional work required to take advantage of it may be more of a barrier than a help. In a perfect world, the clients would have the time to do so, but in an imperfect one it probably just makes more sense for them to update their app when the API changes and munge some URLs with a shell script. The author also conveniently ignores a glaring detail that always makes me angry when people talk about REST as something people should adopt. The simple fact is that browsers don't support REST — no browser supports the PUT or DELETE methods, not to mention other things in the stack like the web server. Yes, Rails has built-in support for REST, but it's accomplished via a disgusting hack whereby hidden form variables are sent to mimic non-supported verbs. I've always felt that saying that people should adopt REST when browsers don't even support it is like saying people should switch to wind power when there are no wind farms producing it. Nice in theory, but not practical and far more trouble than it's worth.