Hacker News new | ask | show | jobs
by joantune 2181 days ago
I see zero examples and rational/practical arguments against the usage of REST.

The only thing here is: it wasn't intended to be used this way.

I see it being called an overload, but I see no alternatives..

This article adds little of value, or even doesn't highlight or enunciate the disadvantages of using REST for everything.

And on the other hand, the advantages are obvious

3 comments

> 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...

I think he would have gotten his point across much more easily with examples and alternatives like you did
See, I wish the author on the original article added the same reference and examples that you added here
The problem isn't that REST as a concept was not intended to be used in some way, it's that "REST" as a word is used when people actually mean "HTTP".
> This article adds little of value, or even doesn't highlight or enunciate the disadvantages of using REST for everything

I think it very clearly states that REST is not that well suited in situation where we actually want RPC.

> I see it being called an overload, but I see no alternatives..

Well, there are alternatives when RPC is needed, e.g. SOAP.