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

181–190 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#181

Post by programmarchy »

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.

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

Re: Most RESTful APIs aren't really RESTful

#183

Post by thom »

JimDabell wrote: post #24
thom wrote: post #13

I struggle to believe that any API in history has been improved by the developer more faithfully following REST’s strictures. The closest we’ve come to actually decoupled, self describing APIs is MCP, and that required inventing actual AIs to understand them.

The most successful API in history – the World-Wide Web – uses REST principles. That’s where REST came from. It was somebody who was involved in the creation of the early web who looked at it and wrote down a description of what properties of the web made it so successful.

This is, almost canonically, the subject of Joel Spolsky's architecture astronauts essay.

Re: Most RESTful APIs aren't really RESTful

#184

Post by Tokumei-no-hito »

Traubenfuchs wrote: post #151
thaumasiotes wrote: post #110

Earlier quoted context omitted.

What is the problem with posting to /user/signup that posting to /user:signup solves?

You might not want a dedicated „Signup“ entity in your model and db.

you would POST to /users

what's the confusion? you're creating a new user entity in the users collection.

Re: Most RESTful APIs aren't really RESTful

#185

Post by LinXitoW »

lucideer wrote: post #129
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…

> - CRUD actions are mapped to POST/GET/PUT/DELETE Agree on your other three but I've seen far too many "REST APIs" with update, delete & even sometimes read operations behind a POST. "SOAP-style REST" I like to call it.

I actually had to change an API recently TO this. The request payload was getting too big, so we needed to send it via POST as a body.

Re: Most RESTful APIs aren't really RESTful

#186

Post by naasking »

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 linked from that start point.

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 constructors that accept standardized objects?

This is what discoverability via HATEOAS is. True REST can be seen as exporting an object model with reflection capabilities. For clients that are familiar with your API, they are using hypermedia to access known/named properties and methods, and generic clients can use reflection to do the same.

Re: Most RESTful APIs aren't really RESTful

#187

Post by ivan_gammel »

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…

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

Many server-rendered websites support REST by design: a web page with links and forms is the state transferred to client. Even in SPAs, HATEOAS APIs are great for shifting business logic and security to server, where it belongs. I have built plenty of them, it does require certain mindset, but it does make many things easier. What problems are you talking about?

Re: Most RESTful APIs aren't really RESTful

#188

Post by naasking »

programmarchy wrote: post #181
naasking wrote: post #158

Earlier quoted context omitted.

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

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

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

Re: Most RESTful APIs aren't really RESTful

#189

Post by LinXitoW »

mrweasel wrote: post #112
k2xl wrote: post #102

Earlier quoted context omitted.

This is very true. Over my 15 years of engineering, I have never suffered_that_ much with integrating with an api (assuming it exists). So the lack of "HATEOaS" hasn't even been noticable for me. As long as they get most of the 400 status codes right (specifically 200, 401, 403, 429) I usually have no issuss integrating and don't even notice that they don't have some "discoverable api". As long as I can get the data…

> As long as they get most of the 400 status codes right (specifically 200, 401, 403, 429) A client had build an API that would return 200 on broken requests. We pointed it out and asked if maybe it could return 500, to make monitoring easier. Sure thing, next version "Http 200 - 500", they just wrote 500 in the message body, return remained 200. Some developers just do not understand http.

I've had frontend devs ask for this, because it was "easier" to handle everything in the same then callback. They wanted me to put ANY error stuff as a payload in the response.

Re: Most RESTful APIs aren't really RESTful

#190

Post by nchmy »

layer8 wrote: post #173
nchmy wrote: post #149

Earlier quoted context omitted.

Sorry, perhaps we're talking past each other. Fielding was absolutely not saying that his REST was the One True approach. But it DOES mean something The issue at hand here is that he coined REST and the whole world is using that term for something completely unrelated (eg an http json api). You could start writing in binary here if you thought that that would be a more appropriate way to communicate, but it wouldn't…

It may mean something, but Roy Fielding went out of his way, over many years, to not talk about the actual use cases he had in mind. It would have been easy for him to clarify that he was only talking about interactive browser applications. But he didn’t. And the people who came up with HATEOAS didn’t think he was. Nor did any of the blog articles that are espousing the alleged virtues of RESTfulness. So it’s not sur…

How are web browsers hypothetical? We're using one with rest/hateoas/hypermedia right now...

You don't seem to have even the slightest idea of what you're talking about here. Again, I suggest checking out the htmx essays and their hypermedia.systems book

Post reply on HN