Critique of REST?

[floop]

Rich Hickey recently mentioned “you can do all kinds of transformations related to RESTful stuff (which I don’t really believe in)…”

Does anyone know what this critique of REST might be?

[beders]

Having been a proponent of RESTful architectures, almost all negative commentary about REST I’ve heard over the years stem from the fact that people don’t understand when it should be used and it shouldn’t be used.
REST is an architectural style and it doesn’t apply everywhere.

Roy Fielding describes REST as an architectural style for distributed hypermedia systems on internet scale.
Systems that need to talk to each other in a reliable, future-proof way.

If that doesn’t apply to the software you are building, you probably shouldn’t adopt a RESTful architecture.

Unfortunately people then have adopted a CRUD-style RESTish way of exchanging data between systems that - due to it being tunneled through HTTP and using human-readable data formats - have enjoyed some success.
Roy itself has criticized these approaches, yet they are now the majority of “REST” APIs out there.

Rich mentioned AWS API Gateway, which allows you to build CRUD-style REST interfaces, but doesn’t really help you much in regards to building a RESTful architecture. (I consider OpenAPI/swagger which API Gateway supports as RESTish. At best).
It is unclear what he doesn’t believe in there: RESTful as an approach to hypermedia systems or the RESTish approach employed by API Gateway.

Given the success of REST (as implemented via HTTP and your browser) it is hard to argue against it.
It’s not hard to argue against RESTish though

I can elaborate for several more pages on that

[floop]

Maybe the best sources to find REST critiques is GraphQL vs REST comparisons like this?

[robheghan]

I believe his problem with rest is that you’re complecting addressing (what do I want to do) with data (here’s the parameters you need to complete the action). Worse yet, you’re mangling it into a string.

For instance: POST http://something.com/purchase/45

Could be better describe as:

{ type: :post 
  host: "something.com"
  method: :http 
  action: :purchase 
  :purchase/item 45
}

I could very well be wrong though.

[beders]

There’s no complecting. A URL is just that. A uniform resource location. It could as well be opaque.

Here’s Fieldings critique on how REST is being misused that also sheds some light on putting information into URLs or how clients are supposed to build URLs.
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

In particular:

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations.

Unfortunately many RESTish APIs rely on out-of-band information exclusively. Mostly because it is deemed too much work for both server and client to use HATEOS to guide a client.

[floop]

Yeah, that’s an issue with Cognitect’s critiques. When criticizing OOP, they mean the mainstream definition, but tacitly let you figure that out from context. (IIRC, Rich also has a critique of Alan Kay style OOP, but that’s separate.)

So I imagine here Rich means mainstream REST.

[doubleelbow]

Beders offered great explanations and resources already. I’d just like to expand a bit on benefits of guiding a client.

The guiding is done through a well defined media type (like HTML) and it’s important because it enables representations of different domains without the need to change existing clients. We would be in quite a mess if browsers would have to be updated to correctly show new websites.

The RESTish APIs are basically RPCs and fall short of REST because they are concerned just with which functions are available for client to call and how should they be called (parameters, shape of data) but it’s always on client to come up with the way of providing correct values for parameters.

If you look at any given HTML file you always know what actions can client take next and how to obtain values for parameters of these actions. Actually it’s almost always (as always). It’s javascript that complicates matters. The prevalent use of javascript in today’s apps is a pet peeve of mine because it shows that HTML is not appropriate for the apps we are writing. Surely we can do better. It’s not easy but it might be simpler.