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

541–550 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#541

Post by sporkland »

As someone that criticized a number of their employers API's for not being sufficiently ReSTful especially with regards to HatEoS, I eventually realized the challenge is the clients. App developers and client developers mostly just want to deal with structured objects that they've built fixed function UX around (including the top level) and desire constructing URLs on the client. It takes a special kind of developer to desire building special mini-browsers everywhere that would require hateos and from the server side.

I think LLM's are going to be the biggest shift in terms of actually driving more truly ReSTful APIs, though LLM's are probably equally happy to take ReST-ish responses, they are able to effectively deal with arbitrary self describing payloads.

MCP at it's core seems to design around the fact that you've got an initial request to get the schema and then the payload, which works great for a lot of our not-quite-ReST API's but you could see over time just doing away with the extra ceremony and doing it all in one request and effectively moving back in the direction of true ReST.

Re: Most RESTful APIs aren't really RESTful

#542

Post by cryptonector »

imtringued wrote: post #36

I find it pretty shocking that this was written in 2025 without a mention of the fact that the only clients that are evolvable enough to interface with a REST API can be categorized to these three types: 1. Browsers and "API Browsers" (think something like Swagger) 2. Human and Artificial Intelligence (basically LLMs) 3. Clients downloaded from the server You'd think that they'd point out these massive caveats. After…

> the only clients that are evolvable enough to interface with a REST API can be categorized to these three types

You mention swagger. Swagger is an anti-REST tech. Defining a media type is the REST equivalent of writing a swagger API description.

If you can define an API in swagger, you can define one via a media type. It's just that the latter is generally not done because to do it requires a JSON schema (or similar) and people mostly don't use that or think of that as how one defines an API.

Boss: we need an API for XYZ

Employee: sure thing boss, I'll write it in swagger and implement by Friday!

Re: Most RESTful APIs aren't really RESTful

#543

Post by hosh »

My biggest takeaway from Roy Fielding's dissertation wasn't how to construct a RESTful architecture or what is the one true REST, but how to understand any computer architecture -- particularly their constraints -- in order to design and implement appropriate systems. I can easily identify anti-patterns (even in implementations) because they violate the constraints which in turns, takes away from the properties of the architecture. This also quickly allows me to evaluate and understand libraries, runtimes, topologies, and so forth.

I used to get caught up in what is REST and what is not, and that misses the point. It's similar to how Christopher Alexander's ideas pattern languages gets used in a way now that misses the point. Alexander was cited in introductory chapter of Fielding's dissertation. These are all very big ideas with broad applicability and great depth.

When combined with Promise Theory, this gives a dynamic view of systems.

Re: Most RESTful APIs aren't really RESTful

#544

Post by paulddraper »

brigandish wrote: post #506
paulddraper wrote: post #441

Earlier quoted context omitted.

What is the limited support for CONNECT/HEAD/OPTIONS/PUT/DELETE ?

It was limited up until the last 10 years, and if someone hasn't updated their knowledge then it's still limited, I suppose.

XMLHttpRequest? fetch?

We're talking JSON APIs -- HTML forms are incompatible with that no matter the verb.

Re: Most RESTful APIs aren't really RESTful

#545

Post by cyberax »

motorest wrote: post #503
cyberax wrote: post #447

Earlier quoted context omitted.

Wait until you hear about errors in REST...

What about errors in REST? It's HTTP status codes, and implementations are free to pick whatever approach they want for response documents. Some frameworks default to using Problem Details responses, but no one forces that.

You can't rely on them because they can come from middleboxes (load balancers, proxies, captive portals in hotels, etc.).

So you can't rely on having structured errors for common codes such as 401/403/404, it's very typical to get unstructured text in payloads for such errors. Not a few REST bindings just fail with unhelpful serialization exceptions in such cases.

Re: Most RESTful APIs aren't really RESTful

#546

Post by cyberax »

motorest wrote: post #514
cyberax wrote: post #505

Earlier quoted context omitted.

This is a recent project. REST happened basically in the environment where your choices were CORBA, DCOM, SOAP and other such monstrosities. Of course, REST won handily. We're not in this environment anymore, thankfully, and REST now is getting some well-deserved scrutiny.

> This is a recent project. OData officially started out in 2007. Roy Fielding's thesis was published in 2000.

So it was a contemporary of Protobufs, Cap’n Proto, and other frameworks. Facebook had Thrift, Amazon had Coral, and so on.

They appeared almost simultaneously, for the very same reason: REST by itself is too vague and unreliable.

Re: Most RESTful APIs aren't really RESTful

#547

Post by potamic »

Joker_vD wrote: post #537
potamic wrote: post #487

Earlier quoted context omitted.

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…

> The client in most cases does not care about why something failed, only whether it has failed. "...and therefore using different status codes in the responses is mostly pointless. Therefore, use 200 and put "s":"error" in the response". > Being able to tell apart if the failure was due to reverse proxy or database or whatever is the server's concern. One of the very common failures is for the request to simply neve…

I did say most cases, not all cases. There are some concerns that are considered cross cutting, to have made it into the standard. For instance, many clients will handle a 401 by redirecting to an auth flow, or handle a 429 rate limited by backing off before making a request, handle 426 by upgrading the protocol etc. Not all statuses may be relevant for a given system, you can club several scenarios under a 400 or a 500 and that's perfectly fine for many use cases. But when you have cross cutting concerns, it's beneficial to follow fine grained status codes. It gives you a lot of flexibility in how you can connect different parts of your architecture and reduces integration headaches.

I think a more precise term for what you're describing is transport errors vs business errors. You're right that you don't want to model all your business errors as HTTP status codes. Your business scenarios are most certainly numerous and need to be much more fine grained than what the standard offers. But the important thing is all errors business or transport eventually need to map to a HTTP status code because that's the protocol you're ultimately speaking.

Re: Most RESTful APIs aren't really RESTful

#548

Post by Balooga »

mixedbit wrote: post #513
uzerfcwn wrote: post #414

Earlier quoted context omitted.

> Most web apps today use APIs that return JSON and are called by JavaScript. Can you use REST for such services You kind of could, but it's a bad idea. A core tenet of the REST architecture is that it supports a network of independent servers that provide different services (i.e. webpages) and users can connect to any of them with a generic client (i.e. a web browser). If your mission is to build a specialized API f…

Thanks for the insight. This very well matches my experience from the top comment of this thread. I added discovery related functionality to JSON based API in an attempt to follow REST and didn't see any benefits from the extra work and complexity. Understanding that REST is inherently for HTML (or a similar hypertext based generic client) and it doesn't make sense to try to match it with JSON+JS based API is very re…

Keep in mind that Fielding used his "REST" principles to drive work on the release of HTTP 1.1 in 1999. He subsequently codified these RESTful principles in his dissertation in 2000. The first JSON message was sent in 2001. The reason RESTful is perfectly suited to the WWW is because REST drove HTTP 1.1, not the other way around.

Now days there are just so many use cases where an architecture is more suited to RPC (and POST). And trying to bend the architecture to be "more RESTful" just serves to complicate.

Re: Most RESTful APIs aren't really RESTful

#549

Post by bborud »

rplnt wrote: post #410
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.

You can mess up grpc just as much. Errors are a good place to start.

Could you elaborate?

Re: Most RESTful APIs aren't really RESTful

#550

Post by bborud »

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.

I don't see the point of ConnectRPC.
Post reply on HN