Hacker News Reader

Comment by peteretep | Hacker News Reader

I wish anything built on REST would die. Conflation of the envelope and the payload is idiotic and adds only pain, no value.

View on HN

REST is more or less a description of the architectural design principles that made the web a success. You wish for the web to die?

Fielding has no problem recognizing the web needs one architectural style, and small-grained data APIs need another. The web doesn't need to "die". Our infinite ignorance on what REST is and what it should be used for has to die. Fielding hasn't mentioned the word "API" once in his paper. This entire REST API movement is a paradox that mocks everything he explicitly warned us about in his dissertation.

I've gotten value from HTTP responses in the 300s, 400s, and 500s being handled appropriately by various tools without having to write special RPC logic for those cases. What am I missing?

That a 404, 301, and 500 being generated by the API vs the web server are very different events and it’s hard to think of where “various tools” handling them the same is the right choice? What examples do you have where it’s the right choice?

With application servers acting as the authoritative state of a user's current phonecall status, the api client wants a websocket connection to the shard with that user's state. It connects to one and is 302'd to the appropriate shard. It how has a websocket connection directly to the authoritative source to get notified of any state changes.

I forget exactly what the scenario was but the request was not being sent with credentials so a 401 was returned, which immediately prompted a retry with the credentials. I'd probably agree that this is covering up an issue that should be fixed.

How is this a REST API rather than just a regular API being served over HTTP?

Curiously the websocket spec says the server may send 30x code during handshake, but the client is "not required to follow it".

So in this case you're relying on a specific client's decision more than you're relying on universal interface.

HTTP and REST are never reliably supported by clients. For example, many JavaScript clients will throw exceptions for 4xx and 5xx errors, even though handling 4xx errors in the client application is very reasonable.

Other clients only treat 5xx as a throwable exception, and some don't throw unless the request fails to hit the HTTP server.

Because of these issues, your best bet is to just wrap your HTTP API in a native client library. You certainly can't target a generic HTTP or REST wrapper.

That's a reflection on a small number of Yet Another Not Invented Here clients, as opposed to the protocol and paradigm

Yes, I agree it is not a reflection of the protocols. It doesn't matter either way -- if you have a standard that no one fully implements, your standard is not practically meaningful.

I think partially implemented standards are very useful! You can partially implement in a way that provides escape hatches for users, or you can lock them in to your assumption of the right behaviour.

That said, I think there are very many http clients that implement enough of the standards to me incredibly rich and in line with the spirit of the protocol. The web for humans and machines is based on http. It can improve, but the standard has quite sufficient support to be called practically meaningful

> I've gotten value from HTTP responses in the 300s, 400s, and 500s being handled appropriately by various tools without having to write special RPC logic for those cases. What am I missing?

What exactly is behind this statement?

What tools do you have in mind, and what do they do with 400s and 500s? Other than Chrome DevTools coloring the response in red automatically, a big win. /s

I've also never seen an API redirect and force a pointless second (and third etc.) roundtrip for the client to get the same exact content.

Just because (some) of these codes mean something for a web page and a browser, doesn't mean they're automatically meaningful for a real-world API. That's the critical distinctions, which REST fans refuse to acknowledge.

Middleware comes to mind (eg caches, proxies, api gateways).

That's a constructive comment based on a well rounded understanding of the various architectures and paradigms around. You sound well balanced and like you're a pleasure to work with.

I wish rebuilding RPC infrastructure every couple of years would die, I already lost count of how many times since DCE RPC was cool.

Unlike everyone improvising on "what it means to be REST", no one is shoving RPC down your throat.

They surely are, when the libraries I have to plug into decide it is time to reboot their eco-system and offer only the new way as the path forward.

And what libraries are those...?

Reply on news.ycombinator.com