[MichaelGG]

The web itself is hardly REST. Plus it's not really an API as in easily consumed by a machine. Most web pages, or the user agent, really rely on a human driving decisions.

Seriously, what's a popular API used by developers that's actually truly REST? All I usually see is various levels of awkwardness as an RPC message is sorta split up into various bits spread throughout the HTTP request.

[dragonwriter]

> The web itself is hardly REST.

HTTP/1.0 provided the inspiration for REST, which was defined by Fielding in parallel with work on HTTP/1.1 which it informed. The web itself is very much REST, essentially being the defining instance of the architectural style.

> Plus it's not really an API as in easily consumed by a machine.

Yes, it actually is a REST API that is actually made to be, and regularly used as, an interface consumed as hypertext by machines who access requested content by locator, choose how to handle it by identified media type, identify and either directly act on or present user options to act on related content by hypermedia links, etc. Whether this is end-user software (browsers) or unattended software (Googlebot and other spiders), etc.

[MichaelGG]

I think you are really trying to dodge the question. Spiders often employ plenty of AI to try to make sense of stuff. It's not an API in any useful sense. For instance, automating Amazon.com. Humans manage fine because underlying changes and renamed URLs, input fields, etc. are ignored. A spider can't handle that (buying items, updating kindle preferences, etc.)

But for values of API that you know I'm referring to, where is one popular, truly REST API? Say, one that includes an SDK, if you need help with the definition. The fact that no one can really point out a good example means it's irrelevant to program writers.

Also, if you're saying the web is all REST essentially by definition, then so are these POST-only APIs, but they aren't. Or it's a useless tautology.

Plus I don't see any real difference in the web of HTTP1 vs 1.1, so that whole claim is suspect too. Perhaps you can elaborate exactly what HTTP1.1 added that really changed anything except some ease of use (host header, absolute URLs, keep alive).

[sk5t]

There's a lot of academic hand-wringing about what makes real REST... but not one complete example of which I am aware. I think we're past the brink of just giving up on dogmatic RESTfulness and ought just apply the term to any reasonably sane JSON RPC-style API with out-of-band documentation for humans.

[dragonwriter]

Look, if the actual REST architectural style isn't what you want, then don't use it. But that doesn't make it useful to use the term to refer to things that aren't using it. If you want to make a JSON RPC API, call it a JSON RPC API, not a REST API.

[MichaelGG]

Agreed. I've no idea why everyone is so hot on saying REST. I think it's just a backlash reaction to SOAP and other complicated things, and they really mean "simpler interface" and RPC makes people think CORBA and DCOM? Or maybe the fact a PhD thesis is involved makes them feel more grown up. Like the backlash of shitty statically typed languages leading to people professing a desire for dynamic types instead of type inference. Or just buzzwordy, like people were saying SOA everywhere and now saying microservice.

[sk5t]

The issue is not related to any personal taste or distaste for the REST style, it's that the paucity of idiomatic, complete examples and practical references has permitted the repurposing of the term "RESTful" to mean JSON RPC, and going hand-in-hand with that problem, nobody(?) is trying to implement Fielding-grade REST APIs.

[dragonwriter]

Actual REST may well not be the right solution for quite a lot of the problems people have with APIs, so its good that people should not always feel obligated to use REST.

OTOH, actual REST may well be the solution for other problems, and its a lot easier to talk about solutions if we use "REST" to refer to Representational State Transfer as defined by Fielding and let all things that aren't that get names that reflect what they are, whether its JSON-RPC-over-HTTP or something else.

Its a lot harder to talk about the merits of different approaches if a wide swath of unrelated approaches that are not similar except in not being SOAP+WSDL (or, possibly, in that plus also not being Fielding's Representational State Transfer) all get lumped together as "REST".