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

351–360 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#351

Post by tshaddox »

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.

I also use Google Maps, YouTube, Spotify, and Figma in the same web browser. But surely most of the functionality of those would not be considered HATEOAS.

Re: Most RESTful APIs aren't really RESTful

#354

Post by temporallobe »

Some of this is sensible. I especially like the idea of an interactive starting point which gives you useful links and info, but I can see how that would be difficult with more complex calls — showing examples and providing rich documentation would be difficult. Otherwise, just follow the recommendations for REST verbs (so what if they mostly map to CRUD?), and document your API well. Tools like Swagger really make this quite easy.

Re: Most RESTful APIs aren't really RESTful

#355

Post by JaggerJo »

REST almost never is worth it. It’s a nice idea, but in practice things often are more complicated.

API quality is often not relevant to the business after it passes the “mostly works” bar.

I’ll just use plain http or RPC when it’s not important and spend more time on things that make a difference.

Re: Most RESTful APIs aren't really RESTful

#356

Post by wstrange »

smaudet wrote: post #344
cle wrote: post #228

Earlier quoted context omitted.

For me the battle is with people who want to waste time bikeshedding over the definition of "REST" and whether the APIs are "RESTful", with no practical advantages, and then having to steer the conversation--and their motivation--towards more useful things without alienating them. It's tiresome.

It was buried towards the bottom of the article, but the reason, to me: Clients can be almost automatic with a HATEOS implementation, because it is a self describing protocol. Of course, Open API (and perhaps to some extent now AI) also mean that clients don't need to be written they are just generated. However it is important perhaps to remember the context here: SOAP is and was terrible, but for enterprise that nee…

> Clients can be almost automatic with a HATEOS implementation, because it is a self describing protocol.

That was the theory, but it was never true in practice.

The oft comparisons to the browser really missed the mark. The browser was driven by advanced AI wetware.

Given the advancements in LLMs, it's not even clear that RESTish interfaces would be easier for them to consume (say vs. gRPC, etc.)

Re: Most RESTful APIs aren't really RESTful

#357

Post by michaelsbradley »

ohdeargodno wrote: post #107
porridgeraisin wrote: post #64

Earlier quoted context omitted.

> RPC with status codes Yes. All endpoints POST, JSON in, JSON out (or whatever) and meaningful HTTP status codes. It's a great sweet spot. Of course, this works only for apps that fetch() and createElement() the UI. But that's a lot of apps. If I don't want to use an RPC framework or whatever I just do: { method: "makeBooking", argument: { one: 1, two: "too", }, ... } And have a dictionary in my server mapping metho…

>All endpoints POST This makes automating things like retrying network calls hell. You can safely assume a GET will be idempotent, and safely retry on failure with delay. A POST might, or might not also empty your bank account. HTTP verbs are not just for decoration.

If you're doing well-formed RPC over POST, as opposed to ad hoc RPC (which, let's be honest, is the accurate description for many "REST" APIs in the wild), then requests and responses should have something like an `id` field, e.g. in JSON-RPC:

https://www.jsonrpc.org/specification#request_object

Commonly, servers shouldn't accept duplicate request IDs outside of unambiguous do-over conditions. The details will be in the implementations of server and client, as they should be, i.e. not in the specification of the RPC protocol.

Re: Most RESTful APIs aren't really RESTful

#358

Post by PaulHoule »

mardifoufs wrote: post #346
PaulHoule wrote: post #325

Earlier quoted context omitted.

Fielding won the war precisely because he was intellectually incoherent and mostly wrong. It's the "worse is better" of the 21st century. RPC systems were notoriously unergonomic and at best marginally successful. See Sun RPC, RMI, DCOM, CORBA, XML-RPC, SOAP, Protocol Buffers, etc. People say it is not RPC but all the time we write some function in Javascript like const getItem = async (itemId) => { ... } which does…

I'm not super familiar with SOAP and CORBA, but how is SOAP any more coherent than a "RESTful" API? It's basically just a bag of messages. I guess it involves a schema, but that's not more coherent imo, since you just end up with specifics for every endpoint anyways. CORBA is less "incoherent", but I'm not sure that's actually helpful, since it's still a huge mess. You can most likely become a lot more proficient wit…

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

Circa 2006 I was working on a site that needed to calculate sales tax and we were looking for an API that could help with that. One vendor uses SOAP which would have worked if we were running ASP.NET but we were running PHP. In two days I figured out enough to reverse engineer the authentication system (docs weren't quite enough to make something that worked) but then I had more problems to debug. A competitive vendor used a much simpler system and we had it working in 45 min -- auth is always a chokepoint because if you can't get it working 100% you get 0% of the functionality.

HTTP never had an official authentication story that made sense. According to the docs there are basic, digest, etc. Have you ever seen a site that uses them? The world quietly adopted cookie-based auth that was an ad-hoc version of JSON Web Tokens, once we got an intellectually coherent spec snake oil vendors could spam HN with posts about how bad JWT is because... It had a name and numerous specifics to complain about.

Look at various modern HTTP APIs and you see auth is all across the board. There was the time I did a "shootout" of roughly 10 visual recognition APIs, I got all of them working in 20-30 mins except for Google where I had to install a lot of software on my machine, trashed my Python, and struggled mightily because... they had a complex theory of authentication which was a barrier to doing anything at all.

Worse is better.

Re: Most RESTful APIs aren't really RESTful

#359

Post by andoando »

troupo wrote: post #257
tgv wrote: post #159

Earlier quoted context omitted.

Do you care? From my point of view, post, put, delete, update, and patch all do the same. I would argue that if there is a difference, making the distinction in the url instead of the request method makes it easier to search code and log. And what's the correct verb anyway? So that's an argument that there may be too many request methods, but you could also argue there aren't enough. But then standardization becomes…

> From my point of view, post, put, delete, update, and patch all do the same. That's how we got POST-only GraphQL. In HTTP (and hence REST) these verbs have well-defined behaviour , including the very important things like idempotence and caching: https://github.com/for-GET/know-your-http-well/blob/master/m...

The defined behaviors are not so well defined for more complex APIs.

You may have an API for example that updates one object and inserts another one, or even deletes an old resource and inserts a new one

The verbs are only very clear for very simple CRUD operations. There is a lot of nuance otherwise that you need documentation for and having to deal with these verbs both as the developer or user of an API is a nuisance with no real benefit

Re: Most RESTful APIs aren't really RESTful

#360

Post by cyberax »

bborud wrote: post #341
PaulHoule wrote: post #325

Earlier quoted context omitted.

Fielding won the war precisely because he was intellectually incoherent and mostly wrong. It's the "worse is better" of the 21st century. RPC systems were notoriously unergonomic and at best marginally successful. See Sun RPC, RMI, DCOM, CORBA, XML-RPC, SOAP, Protocol Buffers, etc. People say it is not RPC but all the time we write some function in Javascript like const getItem = async (itemId) => { ... } which does…

What RPC mechanisms, in your opinion, are the most ergonomic and why? (I have been offering REST’ish and gRPC in software I write for many years now. With the REST’ish api generated from the gRPC APIs. I’m leaning towards dropping REST and only offering gRPC. Mostly because the generated clients are so ugly)

Just use gRPC or ConnectRPC (which is basically gRPC but over regular HTTP). It's simple and rigid.

REST is just too "floppy", there are too many ways to do things. You can transfer data as a part of the path, as query parameters, as POST fields (in multiple encodings!), as multipart forms, as streaming data, etc.

Post reply on HN