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

491–500 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#491

Post by motorest »

bornfreddy wrote: post #396
PaulHoule wrote: post #358

Earlier quoted context omitted.

SOAP, CORBA and such have a theory for everything (say authentication) It's hard to learn that theory, you have to learn a lot of it to be able to accomplish anything at all, you have to deal with build and tooling issues, but if you look closely there will be all sorts of WTFs. Developers of standards like that are always implementing things like distributed garbage collection and distributed transactions which are…

Agree with most of what you said, except about HTTP Basic auth. That is used everywhere - take a look at any random API and there is roughly 90% chance that this is the authentication mechanism used. For backends which serve a single frontend maybe not so much, but still in places.

> That is used everywhere - take a look at any random API and there is roughly 90% chance that this is the authentication mechanism used.

I have no idea where you got that idea from. I'm yet to work in a project where any service doesn't employ a mix of bearer token authentication schemes and API keys.

Re: Most RESTful APIs aren't really RESTful

#492

Post by masklinn »

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…

> Should REST without HATEOAS classify as REST? Why not?

Because what got backnamed HATEOAS is the very core of what Fielding called REST: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

Everything else is window dressing.

Re: Most RESTful APIs aren't really RESTful

#493

Post by masklinn »

9dev wrote: post #397
foobarian wrote: post #389

Earlier quoted context omitted.

I've been doing web development for more than a decade and I still can't figure out what REST actually means, it's more of a vibe. When I think about some of the RESTy things we do like return part of the response as different HTTP codes, they don't really add that much value vs. keeping things on the same layer. So maybe the biggest value add so far is JSON, which thanks to its limited nature prevents complication,…

> I've been doing web development for more than a decade and I still can't figure out what REST actually means, it's more of a vibe. While I generally agree that REST isn’t really useful outside of academic thought experiments: I’ve been in this about as long as you are, and it really isn’t hard. Try reading Fieldings paper once; the ideas are sound and easy to understand, it’s just with a different vision of the int…

You can also read Fielding’s old blog posts. He used to write about it a lot before before he stopped blogging.

Re: Most RESTful APIs aren't really RESTful

#494

Post by lucfranken »

osigurdson wrote: post #264
hombre_fatal wrote: post #174

Earlier quoted context omitted.

It also means they made some effort to use appropriate http verbs instead of GET/POST for everything, and they made an effort to organize their urls into patterns like `/things/:id/child/:child_id`. It was probably an organic response to the complexity of SOAP/WSDL at the time, so people harping on how it's not HATEOAS kinda miss the historical context; people didn't want another WSDL.

>> /things/:id/child/:child_id It seems that nesting isn't super common in my experience. Maybe two levels if completely composite but they tend to be fairly flat.

Generally only /companies/:companyId/buildings

And then you get a list of all buildings for this company.

Every building has a url like: /buildings/:buildingId

So you constantly get back to the root.

Only exception is generally a tenant id which goes upfront for all requests for security/scoping purposes.

Re: Most RESTful APIs aren't really RESTful

#495

Post by gherkinnn »

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…

Exactly. What you describe is how I see REST being used today and I wish people accepted the semantic shift and stopped with their well-ackshually. It serves nothing.

Re: Most RESTful APIs aren't really RESTful

#496

Post by lucfranken »

ptdorf wrote: post #455
paulddraper wrote: post #439

Earlier quoted context omitted.

I see both. E.g. GitHub /repos/:owner/:repo/pulls/comments/:comment_id But flat is better than nested, esp if globally unique IDs are used already (and they often are).

Yes but /comments/:comment_uuid that has a parent to /pulls/:pull_uuid is harder to map the hierarchy it belongs to.

Not really if an URL link is added to the post in the comment response.

Also it is possible to embed a sub resource (or part of it).

Think a blog post.

/blogPost/:blogPostId

You can embed a blog object with the url and title so you can show the blogpost on a page with the name of the blog in one go.

If you need more details on the blog you can request /blogs/:blogId

Re: Most RESTful APIs aren't really RESTful

#497

Post by nirui »

Not weird at all if people don't strictly follow a standard.

The world of programming, just like the real world, has a lot of misguided doctrines that looked really good on paper, but not on application.

For example:

    "_links": {
      ....
      "cancel": { "href": "/orders/123/cancel", "method": "POST" }
    }
Why "POST"?

And what POST do you send? A bare POST with no data, or with parameters in it's body?

What if you also want to GET the status of cancellation? Change the type of `method` to an array so you can `"method": ["POST", "GET"]`?

What if you want to cancel the cancellation? Do you do `POST /orders/123/cancel/cancel HTTP/...`, or `DELETE /orders/123/cancel HTTP/...`?

So, people adopt, making an originally very pure and "based" standard into something they can actually use. After all, all of those things are meant to be productive, rather than ideological.

Re: Most RESTful APIs aren't really RESTful

#498

Post by motorest »

troupo wrote: post #241
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…

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

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

GraphQL promised to solve real-world problems.

What real world problems does HATEOAS addresses? None.

Re: Most RESTful APIs aren't really RESTful

#499

Post by cyptus »

potamic wrote: post #487
Joker_vD wrote: post #470

Earlier quoted context omitted.

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

The point of status codes is to have a standard that any client can understand. If you have a load balancer, the load balancer can unhealthy backends based on the status code. Similarly if you have some job scheduler or workflow engine that's calling your API, they can execute an appropriate retry strategy based on the status code. The client in most cases does not care about why something failed, only whether it has…

what is a unhealthy request? is searching for a user which was _not found_ by the server unhealthy? was the request successful? thats where different opinions exist.

Re: Most RESTful APIs aren't really RESTful

#500

Post by motorest »

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…

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

Have you ever heard of HTTP's OPTIONS verb?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

Follow-up trick question: how come you never heard of it and still managed quite well to live without it?

Post reply on HN