Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Most RESTful APIs aren't really RESTful

florian-kraemer.net

Post reply on HN
Print view View original

231–240 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#231

Post by didntcheck »

recursivedoubts wrote: post #168
dwaltrip wrote: post #76

I'll never understand why the HATEOAS meme hasn't died. Is anyone using it? Anywhere? What kind of magical client can make use of an auto-discoverable API? And why does this client have no prior knowledge of the server they are talking to?

Yes. You used it to enter this comment. I am using it to enter this reply. The magical client that can make use of an auto-discoverable API is called a "web browser", which you are using right this moment, as we speak.

The web browser is just following direct commands. The auto discovery and logic is implemented by my human brain

Re: Most RESTful APIs aren't really RESTful

#232

Post by shadowgovt »

ivan_gammel wrote: post #223
montroser wrote: post #210

Earlier quoted context omitted.

Discoverability 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 di…

You 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 g…

How does the UI check if certain operations are available?

Re: Most RESTful APIs aren't really RESTful

#233

Post by cable »

naasking wrote: post #158
motorest wrote: post #144

Earlier quoted context omitted.

> I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. Why do people feel compelled to even consider it to be a battle? As I see it, the REST concept is useful, but the HATEOAS detail ends up having no practical value and creates more problems than the ones it solves. This is in line with the Richardson maturity model[1], where the apex of REST includes all the…

HATEOAS adds lots of practical value if you care about discoverability and longevity.

LLMs also appear to have an easier time consuming it (not surprisingly.)

Re: Most RESTful APIs aren't really RESTful

#234

Post by mariusor »

bnchrch wrote: post #195
mariusor wrote: post #172

Earlier quoted context omitted.

Except for discoverability, nice URLs, and meaningful HTTP methods.

Did you just say "discoverability" is an issue with GraphQL with a straight face? There are plenty of valid criticisms, but that is not one, in fact thats where it shines.

Discoverability of resources starting from a root URL is what I meant, which is probably moot, because GraphQL wants you to use just one. :D

Re: Most RESTful APIs aren't really RESTful

#235

Post by shadowgovt »

naasking wrote: post #186
mixedbit wrote: post #47

When I was working on my first HTTP-based API 13 years ago, based on many comments about true REST, I decided to first study what REST should really be. I've read Fielding's paper cover to cover, I've read RESTful Web Services Cookbook from O'Reilly and then proceeded to workaround Django idioms to provide REST API. This was a bit cargo cult thinking from my end, I didn't truly understand how REST would benefit my se…

> To make truly discoverable API you need to specify protocol for endpoints discovery, operations descriptions, help messages etc. Then you need clients that understand your specification, so it is not really a generic client. Generic clients just need to understand hypermedia and they can discover your API, as long as your API returns hypermedia from its starting endpoint and all other endpoints are transitively lin…

> Generic clients just need to understand hypermedia

Yikes. Nobody wants to implement a browser to create a UI for ordering meals from a restaurant. I'm pretty sure the reason we ended up settling on just tossing JSON blobs around and baking the semantics of them into the client is that we don't want the behavior of the application to get tripped up on whether someone failed to close a tag.

(Besides: practically, for a web-served interface, the client may as well carry semantic understanding because the client came from the server).

Re: Most RESTful APIs aren't really RESTful

#237

Post by Balooga »

mixedbit wrote: post #47

When I was working on my first HTTP-based API 13 years ago, based on many comments about true REST, I decided to first study what REST should really be. I've read Fielding's paper cover to cover, I've read RESTful Web Services Cookbook from O'Reilly and then proceeded to workaround Django idioms to provide REST API. This was a bit cargo cult thinking from my end, I didn't truly understand how REST would benefit my se…

> Fielding's paper doesn't provide a complete recipe for building self-discoverable APIs.

But it does though. A HTTP server returns a HTTP response to a request from a browser. The request is a HTML webpage that is rendered to the user with all discoverable APIs visible as clickable links. Welcome to the World Wide Web.

Re: Most RESTful APIs aren't really RESTful

#238

Post by gabesullice »

> If you are building a public API for external developers you don’t control, invest in HATEOAS. If you are building a backend for a single frontend controlled by your own team, a simpler RPC-style API may be the more practical choice.

My conclusion is exactly the opposite. In-house developers can be expected (read: cajoled) to do things the "right" way, like follow links at runtime. You can run tests against your client and server. Internally, flexible REST makes independent evolution of the front end and back end easy.

Externally, you must cater to somebody who hard-coded a URL into their curl command that runs on cron and whose code can't tolerate the slightest deviation from exactly what existed when the script was written. In that case, an RPC-like call is great and easy to document. Increment from `/v1/` to `/v2/`, writer a BC layer between them and move on.

Re: Most RESTful APIs aren't really RESTful

#239

Post by kelseyfrog »

Spivak wrote: post #199
naasking wrote: post #188

Earlier quoted context omitted.

And that's fine, but then you're doing RPC instead of REST and we should all be clear and honest about that.

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

What would it take for you to update your assumptions?

Re: Most RESTful APIs aren't really RESTful

#240

Post by Balooga »

s_ting765 wrote: post #212
kccqzy wrote: post #171

Earlier quoted context omitted.

It's not just the original REST that usually has no benefits. The industry's reinterpreted version of weak REST also usually has little to no benefits. Who really cares that deleting a resource must necessarily be done with the DELETE HTTP verb rather than simply a POST?

The DELETE verb exists, there's no reason not to use it.

There is one reason. The DELETE absolutely must be idempotent. If it's not, then use POST.
Post reply on HN