I think it's easier to understand his argument when you think about the problem at scale. Consuming one API is meat and potatoes to most of us; with decent docu

I think it's easier to understand his argument when you think about the problem at scale. Consuming one API is meat and potatoes to most of us; with decent documentation and the REST style largely being followed, API clients can be created rather quickly. However, if I asked you to consume 1000 "REST" APIs, this becomes problematic. There is no agreement on representation, nor is there metadata available to infer commonalities. So what have people done? They've tried to introduce solutions from other "protocols". As mentioned in the article, HAL attempts to introduce a predictable envelope around the data, using links and embedded resources to become so HATEOAS friendly. However, there still are holes. How do I know what to do with links? The rel can tell you only so much - back to the documentation we go. How about we introduce a rel to a schema, like XSD, WADL or JSON Schema? Not many have done that and even fewer enjoy working with them. How about knowing if I can PUT or POST to one of these links? Well the API could support OPTIONS request, but does this suit your data intensive mobile app consuming the API? Not too snappy. We could list them out individually in the representation (thereby replicating the HTTP design through representation) but now the size of the representation is growing dramatically just to support metadata that rarely changes. OData, GData and even CMIS have all tried to take a stab at data communication protocols. Yes, they bring solutions to some of these issues at the cost of complexity and verbosity. Plus, they use use discovery endpoints. And they still tend to fall back on XML over JSON because of use of Atom etc. And now we are halfway back to SOAP. How about the versioning issue? Should client be aware of representation structure changes and adapt accordingly? Well WRML (http://www.wrml.org/ http://www.wrml.org/) tried to take that one on and all the best to you if you read that through once and understand it, never mind implementing the actual clients and servers. As ori_b summarized "REST isn't a protocol, it's a protocol pattern". REST can't fit all scenarios. But I think what's becoming clear is that no-one has found anything better, just more specialized. So the days of auto-building clients to consume APIs is far away. I guess we'll just have to embrace the chaos and keep building snowflakes.