8 ms·
This article doesn't mention linking at all, which is at the heart of REST. Without links, it isn't REST, and most of the suggestions don't have anything to do
by saila 6y ago
This article doesn't mention linking at all, which is at the heart of REST. Without links, it isn't REST, and most of the suggestions don't have anything to do with REST per se. Most of it is just standard JSON-over-HTTP stuff that's implemented in a variety of frameworks and libraries.
EDIT: To be clear, I don't particularly care if an API is "RESTful" or not, as long as it's well-designed and documented, but I think there are interesting/useful ideas in REST that are lost when it's conflated with JSON-over-HTTP.
- CharlesW 6y agoWe could use a name for "standard JSON-over-HTTP stuff that's implemented in a variety of frameworks and libraries". So what shall we call REST without HATEOAS[1]? "RESTless"? [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS
- incrudible 6y agoNo, a truly RESTless API must do away with all the other pointless HTTPisms in REST. If you're using any other method than GET or POST, or any other codes than 400 and 200, you're not truly RESTless.
- NanoWar 6y agoMost of the times I end up with put endpoints with verbs, because that often how businesses work. Objects and processes. Behind a REST resource there is a database table most in of the cases. But what if I want to send an email? POST /emails ? That's RESTless as well!
- incrudible 6y ago> This article doesn't mention linking at all, which is at the heart of REST. Please, just don't do it. Yes, I read the dissertation. It's just not a good idea, it has never given me any practical use whatsoever and has always made dealing with the API more annoying. > Most of it is just standard JSON-over-HTTP stuff that's implemented in a variety of frameworks and libraries. Yes, and we call that REST or RESTful anyway. We'll keep doing it that way. You're going to have to accept it.
- saila 6y agoInteresting. I usually find it easier to generate URLs on the server and more convenient to consume APIs that include links to related resources. The other option is munging URLs on the client side, which can be tedious. I'm genuinely curious as to how including links in the response could make an API harder or more annoying to use.
- firebaze 6y agoYou have to know how to parse the response. This usually requires to know what you will receive, which limits the usefulness of generic link responses somehow
- icod 6y agoTotally agree. HATEOAS is a PITA. Never overcomplicate things. Never add metadata if you don't have to. Just K.I.S.S
- dmitriid 6y agoThe main problem with REST is that it never developed tools even on the level with what we have for GraphQL. Somehow everyone rushed to implement GraphQL schemas, and no one rushed to implement JSON Schemas for example. And JSON Schemas with the right tools are a much more powerful instrument. Same goes for linking, and the rest of HATEOAS. At a company I worked we had an internal tool built for most of this stuff which took a lot of problems with HATEOAS away. Unfortunately, we never opensourced it :(
- dragonwriter 6y ago> The main problem with REST is that it never developed tools even on the level with what we have for GraphQL. REST isn't really designed for the problem of implementing a single, centrally controlled API, and is basically overkill for that. Its made for a decentralized, heterogenous network of resources controlled by different parties, which can have separately evolving relationships. Like, say, the WWW. If you have sufficient tooling around it to consume that kind of heterogenous resource network, it's trivial to apply it to a centralized service, but we don't really have the kind of client tooling for applications other than UIs that makes that nice widely available yet, and everyone wanting walled silos instead of free remixing means that REST is probably an antifeature for lots of API providers even if the tooling was 100% there.
- majkinetor 6y agoNot very useful and adds bunch of boiler + more bandwith for each req. With only links, you don't know semantics and inputs. The benefits are next to 0, and effects on the maintenance are non trivial.
- Lavinski 6y agoI wrote about why linking is useful recently https://www.daniellittle.dev/practical-hypermedia-controls https://www.daniellittle.dev/practical-hypermedia-controls. I've been using Hypermedia in my APIs for a few years now and it's been so useful for making great APIs. One of the things I really love about it is that you can test/use the API directly much more easily, because the knowledge about how to use it is in the API itself, instead of half hardcoded into the client.