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

471–480 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#471

Post by magicalhippo »

nchmy wrote: post #138
Devilspawn6666 wrote: post #133

Earlier quoted context omitted.

In a non-interactive case, what is supposed to be reading a response and deciding which links to do some something with or what to do with them? Let's say you've got a non-interactive program to get daily market close prices. A response returns a link labelled "foobarxyz", which is completely different to what the API returned yesterday and the day before. How is your program supposed to magically know what to do? (w…

Why does "your program" need to know anything? The whole point of hypermedia is that there isn't any "program" other than the web browser that agnostically renders whatever html it receives. If the (backend) "program" development team decides that a foobarxyz link should be returned, then that's what is correct. I suspect that your misunderstanding is because you're still looking at REST as a crud api, rather than wh…

> Why doesn't fielding's conception make sense for non-interactive clients?

> Why does "your program" need to know anything? The whole point of hypermedia is that there isn't any "program" other than the web browser that agnostically renders whatever html it receives.

Seems like you're contradicting yourself here.

If a non-interactive client isn't supposed to know anything and just "render" whatever it gets back, how can it perform useful work on the result?

If it can't, in which sense does REST still make sense for non-interactive clients?

Re: Most RESTful APIs aren't really RESTful

#475

Post by TOGoS »

Joker_vD wrote: post #470
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…

> - The team constantly bikesheds over correct status codes and at least a few are used contrary to the HTTP spec I really wish people just used 200 status code and put encoded errors in the payloads themselves instead of trying to fuse the transport layer's (which HTTP serves as, in this case) concerns with the application's concerns. Seriously, HTTP does not mandate that e.g. "HTTP/1.1 503 Ooops\r\n\r\n" should be…

Eh, if you're doing RPC where the whole request/response are already in another layer on top of HTTP, then sure, 200 everything.

But to me, "REST" means "use the HTTP verbs to talk about resources". The whole point is that for resource-oriented APIs, you don't need another layer. In which case serving 404s for things that don't exist, or 409s when you try to put things into a weird state makes perfect sense.

Re: Most RESTful APIs aren't really RESTful

#476

Post by drewcoo »

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 have seen monstrosities claiming to be rest that use HTTP but actually have a separate set of action verbs, nestled inside of HTTP's.

In a server holding a "deck of cards," there might be a "HTTP GET /shuffle.html" call with the side-effect of performing a server-side randomization operation.

I just made that up because I don't want to impugn anyone. But I've seen API sets full of nonsense just like that.

Re: Most RESTful APIs aren't really RESTful

#477

Post by drewcoo »

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…

> Why do people feel compelled to even consider it to be a battle?

Because September isn't just for users.

Re: Most RESTful APIs aren't really RESTful

#478

Post by osigurdson »

rswail wrote: post #284
osigurdson wrote: post #122

Earlier quoted context omitted.

It isn't clear that HATEOS would be better. For instance: >>Clients shouldn’t assume or hardcode paths like /users/123/posts Is it really net better to return something like the following just so you can change the url structure. "_links": { "posts": { "href": "/users/123/posts" }, } I mean, so what? We've create some indirection so that the url can change (e.g. "/u/123/posts").

Yes, so the link doesn't have to be relative to the current host. If you move user posts to another server, the href changes, nothing else does. If suddenly a bug is found that lets people iterate through users that aren't them, you can encrypt the url, but nothing else changes. The bane of the life of backend developers is frontend developers that do dumb "URL construction" which assumes that the URL format never ch…

>> If you move user posts to another server, the href changes, nothing else does

It isn't clear what insurance you are really buying here. You can't possibly mean another physical server. Obviously that happens all the time with any site but no one is changing links to point to the actual hardware - just use a normal load balancer. Is it domain name change insurance? That doesn't add up either.

>> If suddenly a bug is found that lets people iterate through users that aren't them, you can encrypt the url, but nothing else changes.

Normally you would just fix the problem instead of doing weird application level encryption stuff.

>> The bane of the life of backend developers is frontend developers that do dumb "URL construction" which assumes that the URL format never changes

If those "frontend" developers are paying customers as in the case of AWS, OpenAI, Anthropic then you probably want to make your API as simple as possible for them to understand.

Re: Most RESTful APIs aren't really RESTful

#480

Post by rendall »

Zardoz84 wrote: post #25
makeitdouble wrote: post #2

It felt easier going through the post after reading these bits near the end: > The widespread adoption of a simpler, RPC-like style over HTTP can probably attributed to practical trade-offs in tooling and developer experience > Therefore, simply be pragmatic. I personally like to avoid the term “RESTful” for the reasons given in the article and instead say “HTTP” based APIs.

I prefer call it "REST-like" APIs

Same. And REST for short ;)
Post reply on HN