6 ms·
HATEOAS adds lots of practical value if you care about discoverability and longevity.
by naasking 1y ago
HATEOAS adds lots of practical value if you care about discoverability and longevity.
- programmarchy 1y agoFor most APIs that doesn’t deliver any value which can’t be gained from API docs, so it’s hard to justify. However, these days it could be very useful if you want an AI to be able to navigate your API. But MCP has the spotlight now.
- naasking 1y agoAnd that's fine, but then you're doing RPC instead of REST and we should all be clear and honest about that.
- Spivak 1y agoI think you throw away a useful description of an API by lumping them all under RPC. If you tell me your API is RPC instead of REST then I'll assume that: * If the API is available over HTTP then the only verb used is POST. * The API is exposed on a single URL and the `method` is encoded in the body of the request.
- osigurdson 1y agoIt is true, if you say "RPC" I'm more likely to assume gRPC or something like that. If you say "REST", I'm 95% confident that it is a standard / familiar OpenAPI style json-over-http style API but will reserve a 5% probability that it is actually HATEOAS and have to deal with that. I'd say, if you are doing Roy Fielding certified REST / HATEOAS it is non-standard and you should call it out specifically by using the term "HATEOAS" to describe it.
- kelseyfrog 1y agoWhat would it take for you to update your assumptions?
- Spivak 1y agoPeople in the real world referring to "REST" APIs, the kind that use HTTP verbs and have routes like /resource/id as RPC APIs. As it stands in the world outside of this thread nobody does that. At some level language is outside of your control as an individual even if you think it's literally wrong--you sometimes have to choose between being 'correct' and communicating clearly.
- montroser 1y agoDiscoverability by whom, exactly? Like if it's for developer humans, then good docs are better. If it's for robots, then _maybe_ there's some value... But in reality, it's not for robots. HATEOAS solves a problem that doesn't exist in practice. Can you imagine an API provider being like, "hey, we can go ahead and change our interface...should be fine as long as our users are using proper clients that automatically discover endpoints and programmatically adapt accordingly"? Or can you imagine an API consumer going, "well, this HTTP request delivers the data we need, but let's make sure not to hit it directly -- instead, let's recursively traverse a graph of requests each time to make sure this is still the way to do it!"
- naasking 1y agoThe problems do exist, and they're everywhere. People just invented all sorts of hacks and workarounds for these issues instead of thinking more carefully about them. See my posts in this thread for some examples: https://news.ycombinator.com/item?id=44509745 https://news.ycombinator.com/item?id=44509745
- ivan_gammel 1y agoYou have got it wrong. Let's say I build some API with different user roles. Some users can delete an object, others can only read it. The UI knows about the semantics of the operations and logical names of it, so when UI gets the object from server it can simply check, if certain operations are available, instead of encoding the permission checking on the client side. This is the discoverability. It does not imply generated interfaces, UI may know something about the data in advance.
- tacone 1y agoThat's actually an interesting take, thank you.
- shadowgovt 1y agoHow does the UI check if certain operations are available?
- cable 1y agoLLMs also appear to have an easier time consuming it (not surprisingly.)