4 ms·
No, HATEOAS is not for humans but was imagined for api consumers. All those links that you mentioned in the Github api responses are named and you as a client c
by ssijak 7y ago
No, HATEOAS is not for humans but was imagined for api consumers. All those links that you mentioned in the Github api responses are named and you as a client can use them, where the actual url can change. Also, you as an api consumer can know what actions are available.
That being said, I have never seen developing api client driven mainly by HATEOAS
- einrealist 7y agoImagine an API returning HTML, too. I've built such APIs (not public). I consider it best practice. The HTML representation can be utilized as the frontend. At least, its the interactive documentation to the API. In fact, when I built such APIs, I usually started with the HTML representation.
- legulere 7y agoBut isn’t almost always the link just the current link + the link name? Apart from being able to tell the client what functions they are allowed to use and a very superficial form of documentation I don’t really get the advantage of it.
- ben509 7y ago> All those links that you mentioned in the Github api responses are named and you as a client can use them, where the actual url can change. I think that's a good idea, just like REST and HATEOAS are both ideas trying to solve problems. I'm just skeptical that it'd work in practice. It seems vanishingly unlikely that consumers will use it correctly enough that changing the URLs in that mechanism wouldn't result in making the breakage even more mysterious. When I say "it only makes sense if you've got a browser on the other end," the issue is you need a client approaching the complexity of a browser to do all the redirection and such that makes this level of flexibility for the API implementer to work. I believe something like that is possible, but this isn't the way.