| > I see it being called an overload, but I see no alternatives.. Some APIs make rather poor use of HTTP, using it as a glorified RPC mechanism. Done poorly, this can make caching hard or impossible. A fair number of self-proclaimed "REST" APIs seem to do okay on the HTTP verb part of things, using GET/PUT as HTTP intended, but they insist on naming resources by "IDs" or something, and to then fetch the named resource, require the user of the API to manually construct the URL themselves. This is antithetical to what Fielding's REST proposed, which is that the URL serves as a universal mechanism for naming resources, and that end clients don't need to know anything about how to construct URLs, because they can just follow the one they are given. (And the server can do whatever it wants with URL layout.) Fielding himself notes this on his blog[1], > A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). For practical examples of this, the Azure API is significantly hit or miss here. Some references to other resources are in URI-references (this is a good application of REST) but sometimes it is just a string name and you have to know, out of band, how to construct a URL to that resource. I'd recommend the ACME API as the best application of REST that I am aware of. [1]: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... |