This article doesn't really clarify things for me. I agree that not many APIs in the wild right now are truly RESTful, but this has been stated for years. We know this. The article then posits that true REST is too hard. This is simply not true when you look at the bigger picture. Yes, it may be easier in the moment to cowboy it up and reinvent the wheel, but when it comes to maintaining your service and integrating it with others, you pay the price for lack of foresight.
The questions that need to be answered are how would true REST be different, and why would I want to spend my precious time learning about it and implementing it?
I appreciate the author's enthusiasm towards REST, but I would prefer to discuss the technical merits rather than engage in justification and categorization of what's out there right now. Yeah, it's not REST, and yeah people are going to call it REST anyway in certain contexts. But in the context of architectural design we have clear definitions about what REST is, and there's no need to muddy the waters.
The questions that need to be answered are how would true REST be different, and why would I want to spend my precious time learning about it and implementing it?
This is a pretty good one stop shop for the first question: http://www.nordsc.com/ext/classification_of_http_based_apis....
Martin Fowler's article on the subject is good too: http://martinfowler.com/articles/richardsonMaturityModel.htm...
And this article shows a basic "hello world" implementation of REST, and explains the benefits: http://www.infoq.com/articles/subbu-allamaraju-rest
I appreciate the author's enthusiasm towards REST, but I would prefer to discuss the technical merits rather than engage in justification and categorization of what's out there right now. Yeah, it's not REST, and yeah people are going to call it REST anyway in certain contexts. But in the context of architectural design we have clear definitions about what REST is, and there's no need to muddy the waters.