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

281–290 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#281

Post by bunderbunder »

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 also view it as inevitable.

I can count on one hand the number of times I've worked on a service that can accurately be modeled as just representational state transfer. The rest have at least some features that are inherently, inescapably some form of remote procedure call. Which the original REST model eschews.

This creates a lot of impedance mismatch, because the HTTP protocol's semantics just weren't designed to model that kind of thing. So yeah, it is hard to figure out how to shoehorn that into POST/GET/PUT/DELETE and HTTP status codes. And folks who say it's easy tend to get there by hyper-focusing on that one time they were lucky enough to be working on a project where it wasn't so hard, and dismissing as rare exceptions the 80% of cases where it did turn out to be a difficult quagmire that forced a bunch of unsatisfying compromises.

Alternatively you can pick a protocol that explicitly supports RPC. But that's not necessarily any better because all the well-known options with good language support are over-engineered monstrosities like GRPC, SOAP, and (shudder) CORBA. It might reduce your domain modeling headaches, but at the cost of increased engineering and operations hassle. I really can't blame anyone for deciding that an ad-hoc, ill-specified, janky application of not-actually-REST is the more pragmatic option. Because, frankly, it probably is.

Re: Most RESTful APIs aren't really RESTful

#282

Post by ehutch79 »

recursivedoubts wrote: post #255
ehutch79 wrote: post #248

Earlier quoted context omitted.

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.

Yes. You used such an api to post your reply. And I am using it as well, via the affordances presented by the mobile safari hypermedia client program. Quite an amazing system!

No. I was served HTML. not a json respoise that the browser discovered how to display.

Re: Most RESTful APIs aren't really RESTful

#283

Post by motorest »

commandlinefan wrote: post #214
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…

We should probably stop calling the thing that we call REST, REST and be done with it - it's only tangentially related to what Fielding tried to define.

> We should probably stop calling the thing that we call REST (...)

That solves no problem at all. We have Richardson maturity model that provides a crisp definition, and it's ignored. We have the concept of RESTful, which is also ignored. We have RESTless, to contrast with RESTful. Etc etc etc.

None of this discourages nitpickers. They are pedantic in one direction, and so lax in another direction.

Ultimately it's all about nitpicking.

Re: Most RESTful APIs aren't really RESTful

#284

Post by rswail »

osigurdson wrote: post #122
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…

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

It's brittle and will break some time in the future.

Re: Most RESTful APIs aren't really RESTful

#285

Post by maliciouspickle »

dekhn wrote: post #270

I see a lot of people who read Fielding's thesis and found it interesting. I did not find it interesting. I found it excessively theoretical and proscriptive. It led to a lot of people arguing pedantically over things that just weren't important. I just want to exchange JSON-structured messages over HTTP, using the least amount of HTTP required to implement request and response. I'm also OK with protocol buffers over…

i completely agree with you. the authors approach seems complex and unnecessary. my basic expectation when I see something labeled as a REST API is:

1. i can submit a request via HTTP

2. data is returned as JSON by a response

3. the most minimal amount of HTTP/Pagination necessary is required

Re: Most RESTful APIs aren't really RESTful

#286

Post by Spivak »

kelseyfrog wrote: post #239
Spivak wrote: post #199

Earlier quoted context omitted.

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?

People in the real world referring to "REST" APIs, the kind that use HTTP verbs and have routes like /resource/id as RPC APIs. As it stands in the world outside of this thread nobody does that.

At some level language is outside of your control as an individual even if you think it's literally wrong--you sometimes have to choose between being 'correct' and communicating clearly.

Re: Most RESTful APIs aren't really RESTful

#287

Post by bmn__ »

akvadrako wrote: post #267
CSMastermind wrote: post #244

Earlier quoted context omitted.

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

Well you can't reliably use GET with bodies. There is the proposed SEARCH but using custom methods also might not work everywhere.

No, QUERY. https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-saf...

SEARCH is from RFC 5323 (WebDAV).

Re: Most RESTful APIs aren't really RESTful

#288

Post by [deleted] »

nsonha wrote: post #207
_heimdall wrote: post #98

Earlier quoted context omitted.

You realize that anyone using a browser to view HTML is using HATEOS, right? You could probably argue whether SPAs fit the bill, but for sure any server rendered or static site is using HATEOS. The point isn't that clients must have absolutely no prior knowledge of the server, its that clients shouldn't have to have complete knowledge of the server. We've grown used to that approach because most of us have been build…

HATEOAS is anything that serves the talking point now apparently

[deleted]

Re: Most RESTful APIs aren't really RESTful

#289

Post by kelseyfrog »

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?

I used it on an enterprise-grade video surveillance system. It was great - basically solved the versioning and permissions problem at the API level. We leveraged other RFCs where applicable.

The biggest issue was that people wanted to subvert the model to "make things easier" in ways that actually made things harder. The second biggest issue is that JSON is not, out of the box, a hypertext format. This makes application/json not suitable for HATEOAS, and forcing some hypertext semantics onto it always felt like a kludge.

Re: Most RESTful APIs aren't really RESTful

#290

Post by rswail »

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…

The browser is "generic code" that provides the UX we use all day, every day.

REST includes allowing code to be part of the response from a server, there are the obvious security issues, but the browsers (and the standards) have dealt with a lot of that.

https://ics.uci.edu/~fielding/pubs/dissertation/net_arch_sty...

Post reply on HN