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

371–380 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#371

Post by PaulHoule »

cyberax wrote: post #360
bborud wrote: post #341

Earlier quoted context omitted.

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.

People get stuff done despite at all that.

Re: Most RESTful APIs aren't really RESTful

#372

Post by necovek »

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…

To me, the most important nuance really is that just like "hypermedia links" (encoded as different link types, either with Link HTTP header or within the returned results) are "generic" (think that "activate" link), so is REST as done today: if you messed up and the proper action should not be "activate" but "enable", you are in no better position than having to change from /api/v1/account/ID/activate to /api/v2/account/ID/enable.

You still have to "hard code" somewhere what action anything needs to do over an API (and there is more missing metadata, like icons, translations for action description...).

Mostly to say that any thought of this approach being more general is only marginal, and really an illusion!

Re: Most RESTful APIs aren't really RESTful

#373

Post by mixedbit »

MangoToupe wrote: post #370
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…

Personally I never saw "self-discoverable" as a goal, let alone an achievable one, so I think you're overestimating the ambitions of simple client-design. Notably, the term "discoverable" doesn't even appear in TFA.

From the article: 'The phrase “not being driven by hypertext” in Roy Fielding’s criticism refers to the absence of Hypermedia as the Engine of Application State (HATEOAS) in many APIs that claim to be RESTful. HATEOAS is a fundamental principle of REST, requiring that the client dynamically discover actions and interactions through hypermedia links embedded in server responses, rather than relying on out-of-band knowledge (e.g., API documentation).'

Re: Most RESTful APIs aren't really RESTful

#374

Post by LegionMammal978 »

mixedbit wrote: post #373
MangoToupe wrote: post #370

Earlier quoted context omitted.

Personally I never saw "self-discoverable" as a goal, let alone an achievable one, so I think you're overestimating the ambitions of simple client-design. Notably, the term "discoverable" doesn't even appear in TFA.

From the article: 'The phrase “not being driven by hypertext” in Roy Fielding’s criticism refers to the absence of Hypermedia as the Engine of Application State (HATEOAS) in many APIs that claim to be RESTful. HATEOAS is a fundamental principle of REST, requiring that the client dynamically discover actions and interactions through hypermedia links embedded in server responses, rather than relying on out-of-band know…

Fielding's idea of REST does seem pretty pointless. "Did you know that human-facing websites are made out of hyperlinked pages? This is so crazy that it needs its own name for everyone to parrot!" But a web application isn't going to be doing much beyond basic CRUD when every individual change in state is supposed to be human-driven. And if it's not human-driven, then it's protocol-driven, and therefore not REST.

Re: Most RESTful APIs aren't really RESTful

#375

Post by cyberax »

PaulHoule wrote: post #371
cyberax wrote: post #360

Earlier quoted context omitted.

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.

People get stuff done despite at all that.

I mean... I used to get stuff done with CORBA and DCOM.

It's the question of long-term consequences for supportability and product evolution. Will the next person supporting the API know all the hidden gotchas?

Re: Most RESTful APIs aren't really RESTful

#376

Post by jerf »

PaulHoule wrote: post #371
cyberax wrote: post #360

Earlier quoted context omitted.

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.

People get stuff done despite at all that.

I'd agree with your great-grandparent post... people get stuff done because of that.

There has been no lack of heavyweight, pre-declare everything, code-generating, highly structured, prescriptive standards that sloppyREST has casually dispatched (pun fully intended) in the real world. After some 30+ years of highly prescriptive RPC mechanisms, at some point it becomes time to stop waiting for those things to unseat "sloppy" mechanisms and it's time to simply take it as a brute fact and start examining why that's the case.

Fortunately, in 2025, if you have a use case for such a system, and there are many many such valid use cases, you have a number of solid options to choose from. Fortunately sloppyREST hasn't truly killed them. But the fact that it empirically dominates it in the wild even so is now a fact older than many people reading this, and bears examination in that light rather than casual dismissals. It's easy to list the negatives, but there must be some positives that make it so popular with so many.

Re: Most RESTful APIs aren't really RESTful

#377

Post by icedrop »

thom wrote: post #260
JimDabell wrote: post #196

Earlier quoted context omitted.

It’s not. It’s pretty much the opposite. This is what he’s talking about: > our clever thinker invents a new, higher, broader abstraction > When you go too far up, abstraction-wise, you run out of oxygen. > They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line. REST is the opposite. REST is “We did this. It…

That's absolutely not what the essay is about. It's about the misassignment of credit for the success of a technology by people who think the minutiae of the clever implementation was important.

I think you bring up an interesting tangential point that I might agree with--that the people doing the misalignment are how architecture astronauts remain employed.

But the core of Joel Spolsky's three posts on Architecture Astronauts is his expression of frustration at engineers who don't focus on delivering product value. These "Architecture Astronauts" are building layer on layer of abstraction so high that what results is a "worldchanging" yet extremely convoluted system that no real product would use.

A couple choice quotes from https://www.joelonsoftware.com/2008/05/01/architecture-astro...:

> "What is it going to take for you to get the message that customers don’t want the things that architecture astronauts just love to build."

> "this so called synchronization problem is just not an actual problem, it’s a fun programming exercise that you’re doing because it’s just hard enough to be interesting but not so hard that you can’t figure it out."

Re: Most RESTful APIs aren't really RESTful

#378

Post by motorest »

cryptonector wrote: post #297
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…

Defining media types seems right to me, but what ends up happening is that you use swagger instead to define APIs and out the window goes HATEOAS, and part of the reason for this is just that defining media types is not something people do (though they should). Basically: define a schema for your JSON, use an obvious CRUD mapping to HTTP verbs for all actions, use URI local-parts embedded in the JSON, use standard HT…

> (...) and part of the reason for this is just that defining media types is not something people do (...)

People do not define media types because it's useless and serves no purpose. They define endpoints that return specific resource types, and clients send requests to those endpoints expecting those resource types. When a breaking change is introduced, backend developers simply provide a new version of the API where a new endpoint is added to serve the new resource.

In theory, media types would allow the same endpoint to support multiple resource types. Services would sent specific resource types to clients if they asked for them by passing the media type in the accept header. That is all fine and dandy, except this forces endpoints to support an ever more complex content negotiation scheme that no backend framework comes close to support, and this brings absolutely no improvement in the way clients are developed.

So why bother?

Re: Most RESTful APIs aren't really RESTful

#379

Post by troupo »

andoando wrote: post #359
troupo wrote: post #257

Earlier quoted context omitted.

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

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

They are. Your APIs can always be defined as a combination of "safe, idempotent, cacheable"

Re: Most RESTful APIs aren't really RESTful

#380

Post by LegionMammal978 »

recursivedoubts wrote: post #224
physicles wrote: post #213

Earlier quoted context omitted.

This is true, but isn’t this quite far away from the normal understanding of API, which is an interface consumed by a program? Isn’t this the P in Application Programming Interface? If it’s a human at the helm, it’s called a User Interface.

I agree that's a common understanding of things, but I don't think that it's 100% accurate. I think that a web browser is a client program, consuming a RESTful application programming interface in the manner that RESTful APIs are designed to be consumed, and presenting the result to a human to choose actions. I think if you restrict the notion of client to "automated programs that do not have a human driving them" th…

At that level, it would be infinitely clearer to say, "There is no such thing as a RESTful API, since the purpose of REST is to connect a system to a human user. There is only such a thing as a RESTful UI based on an underlying protocol (HTML/HTTP). But the implementation of this protocol (the web browser) is secondary to the actual purpose of the system, which is always a UI."
Post reply on HN