21–30 of 137 posts
If the point is "stop writing procedural REST API clients and write them declaratively instead" then that advice is by no means restricted to REST API clients.
If the point is "hey, I noticed that REST API clients are another thing that we can now comfortably write declaratively" then OK.
While this has some benefits, it seems like a slippery slope leading back to SOAP.
Exactly. But to be precise, REST would be the equivalent of SOAP and the format described in this post would be equivalent to WSDL [1]. And then, we'll need a central location to store all of these API descriptors and UDDI [2] will be back with a vengeance. [1] http://www.w3.org/TR/wsdl [2] http://en.wikipedia.org/wiki/Universal_Description_Discovery...
Sigh. This is optimizing for the wrong problem. Stop creating REST APIs that are only level 1 or 2 (see http://martinfowler.com/articles/richardsonMaturityModel.htm... ). Start writing HATEOS systems where the client is coupled to the semantic rather than the syntax. Machine parseable interface descriptions might get rid of some boilerplate but it doesn't make for a more robust client-server relationship.
We could give a name to the language we use to define such files. It's a language that defines Web services, so perhaps Web Services Description Language? :-) http://en.wikipedia.org/wiki/Web_Services_Description_Langua... Flippancy aside, maybe there's a need for a next generation of this that skips all the XML headaches after all.
We could give a name to the language we use to define such files. It's a language that defines Web services, so perhaps Web Services Description Language? :-) http://en.wikipedia.org/wiki/Web_Services_Description_Langua... Flippancy aside, maybe there's a need for a next generation of this that skips all the XML headaches after all.
http://en.wikipedia.org/wiki/Web_Application_Description_Lan... ?