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

241–250 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#241

Post by troupo »

motorest wrote: post #144
cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

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

> but the HATEOAS detail ends up having no practical value and creates more problems than the ones it solves.

Only because we never had the tools and resources that, say, GraphQL has.

And now everyone keeps re-inventing half of HTTP anyway. See this diagram https://raw.githubusercontent.com/for-GET/http-decision-diag... (docs https://github.com/for-GET/http-decision-diagram/tree/master...) and this: https://github.com/for-GET/know-your-http-well

Re: Most RESTful APIs aren't really RESTful

#243

Post by svieira »

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…

This is actually what we do at [DAYJOB] and it's been working well for over 12 years. Like any other kind of interface indirection it adds the overhead of indirection for the benefit of being able to change the producer's side of the implementation without having to change all of the consumers at the same time.

Re: Most RESTful APIs aren't really RESTful

#244

Post by CSMastermind »

Xenoamorphous wrote: post #137
OJFord wrote: post #87

Earlier quoted context omitted.

> I can safely assume [...] CRUD actions are mapped to POST/GET/PUT/DELETE Not totally sure about that - I think you need to check what they decided about PUT vs PATCH.

Isn't that fairly straightforward? PUT for full updates and PATCH for partial ones. Does anybody do anything different?

Lots of people make PUTs that work like PATCHes and it drives me crazy. Same with people who use POST to retrieve information.

Re: Most RESTful APIs aren't really RESTful

#245

Post by mixedbit »

naasking wrote: post #217
mixedbit wrote: post #198

Earlier quoted context omitted.

> Let me ask you this: if I gave you an object X in your favourite OO language, could you use your languages reflection capabilities to discover all properties of every object transitively reachable from X, and every method that could be called on X and all objects transitively reachable from X? Could you not even invoke many of those methods assuming the parameter types are mostly standardized objects or have constr…

> For things like debugger, REPL, or some database inspection/manipulation tool, this approach is useful, but for most apps exposed to end users Yes, exactly, but the point is that something like Swagger becomes completely trivial, and so you no longer need a separate, complex tool to do what the web automatically gives you. The additional benefits are on the server-end, in terms of maintenance and service flexibilit…

There are many ideas in the REST paper that are super useful, but the goal of making a generic client working with any API is difficult if not impossible to achieve.

Was the client of the service that you worked on fully generic and application independent? It is one thing to be able to change URLs only on the server, without requiring a client code change, and such flexibility is indeed practical benefit that the REST architecture gives us. It is another thing to change say, a calendar application into a messaging application just by returning a different entry point URL to the same generic client code. This goal is something that REST architecture tried to address, but IMO it was not realized in practice.

Re: Most RESTful APIs aren't really RESTful

#246

Post by troupo »

shadowgovt wrote: post #232
ivan_gammel wrote: post #223

Earlier quoted context omitted.

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?

OPTIONS https://datatracker.ietf.org/doc/html/rfc2616

More links here: https://news.ycombinator.com/item?id=44510745

Re: Most RESTful APIs aren't really RESTful

#248

Post by ehutch79 »

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.

So, given a hateos api, and stock firefox (or chrome, or safari, or whatever), it will generate client views with crud functionality?

Let alone ux affordances, branding, etc.

Re: Most RESTful APIs aren't really RESTful

#249

Post by troupo »

motorest wrote: post #153
Cthulhu_ wrote: post #130

Earlier quoted context omitted.

HTTP/JSON API works too, but you can assume it's what they mean by REST. It makes me wish we stuck with XML based stuff, it had proper standards, strictly enforced by libraries that get confused by things not following the standards. HTTP/JSON APIs are often hand-made and hand-read, NIH syndrone running rampant because it's perceived to be so simple and straightforward. To the point of "we don't need a spec, you can…

> HTTP/JSON API works too, but you can assume it's what they mean by REST. This is the kind of slippery slope where pedantic nitpickers thrive. The start to complain that if you accept any media type other than JSON then it's not "REST-adjacent" anymore because JSON is in the name and some bloke wrote down somewhere that JSON was a trait of this architectural style. In this sense, the term "RESTful" is useful to shut…

> The start to complain that if you accept any media type other than JSON then it's not "REST-adjacent" anymore because JSON is in the name and some bloke wrote down somewhere that JSON was a trait of this architectural style.

wat?

Nowhere is JSON in the name of REpresentational State Transfer. Moreover, sending other representations than JSON (and/or different presentations in JSON) is not only acceptable, but is really a part of REST

Re: Most RESTful APIs aren't really RESTful

#250

Post by nico »

cjpearson wrote: post #40

I sympathize with the pedantry here and found Fielding's paper to be interesting, but this is a lost battle. When I see "REST API" I can safely assume the following: - The API returns JSON - CRUD actions are mapped to POST/GET/PUT/DELETE - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec - There's a decent chance listing endpoints were changed to POST to su…

> Like Agile, CI or DevOps you can insist on the original definition or submit to the semantic diffusion and use the terms as they are commonly understood

This is an insightful observation. It happens with pretty much everything

As it has been happening recently with the term vibecoding. It started with some definition, and now it’s morphed into more or less just meaning ai-assisted coding. Some people don’t like it[1]

1: https://simonwillison.net/2025/Mar/19/vibe-coding/

Post reply on HN