3 ms·
Cont.: Because using HTTP verbs and status codes is stupid too: - the API is then tied to single "transport" protocol (it is application layer protocol in ISO/
by janci 4y ago
Cont.: Because using HTTP verbs and status codes is stupid too:
- the API is then tied to single "transport" protocol (it is application layer protocol in ISO/OSI but if you are not building a web browser, your application should reside one layer upwards)
- it crosses ISO/OSI layer boundaries (exposes URLs in data, uses status codes for application error reporting, uses HTTP headers for pagination etc.)
I think the second issue is vastly underrated. Protocols that cross layer boundaries are source of trouble and require tons of workarounds. Do you remember how FTP does not work well with NATs? It's because it exposes IPs and ports - transport layer concepts on application layer. SIP? The same thing.
With true REST you can build only HTTP APIs, no websockets, no CLIs, no native libraries.
- derefr 4y ago> exposes URLs in data That's, uh, the point. Without that, it's not "the web." (And yes, properly-structured APIs are part of "the web" — e.g. the first page of your paginated resource can be on one server, while successive pages are on some other archival server.) This is the whole reason for doing HATEOAS: there's no longer a static assumption that you're working against some specific server with a specific schema structure in place. Rather, your API client is surfing the server, just like you're surfing HN right now. > no websockets Correct in a nominal sense, but not in any sense 99% of developers would care about. Instead of RPC over websockets, do REST. Instead of subscriptions over websockets, do REST against a subscription resource for the control-plane, and then GET a Server-Sent Events stream for the data-plane. Perfectly HATEOAS compliant — nobody ever said resource-representations have to be finite.
- janci 4y ago> This is the whole reason for doing HATEOAS. Seems like a premature optimization to me. Building all applications so that they potentially could be distributed over multiple servers. YAGNI.
- zach_garwood 4y agoHello, this is the internet, have you heard of us?
- derefr 4y agoWe're not talking about centrally-developed distributed applications; we're talking about services that tell you to talk to other services. Services that could very well be developed by other people/organizations, years earlier or later. In fact, services that might very well be "plugins", in the sense that those URLs are user-supplied content from the perspective of the API. (Think: permalink URLs from user-supplied RSS feeds, in the responses of an RSS feed-reader API. Or image URLs, hotlinked in an oldschool phpBB forum. Or RDF vCards.)
- lmm 4y agoYou know what else crosses ISO/OSI layer boundaries? Switches. But I don't see anyone saying hubbed networks are better. And realistically how often are you going to change your "transport"? And if you added an abstraction layer would that actually make it any easier? Stuff like SOAP ends up being the inner-platform effect where you reimplement all of HTTP on top of HTTP and actually implementing a new SOAP transport is just as hard as porting your protocol use a second "transport" if you actually needed to (which you probably won't).
- janci 4y ago> You know what else crosses ISO/OSI layer boundaries? Switches. No, they do not. Switches work at L2 and are only interested in L2 concepts (MAC addresses). They work transparently for any application that is not crossing the L1/L2 boundary. Routers are L3.
- nunez 4y agothey might be talking about switches that also have routers, which is common enough these days to think they are one in the same (they are not, as you noted)