[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".