[nulltype]

I think some of these problems are solved by HTTP/2 multiplexing.

My experience at least with using REST for APIs seems to agree with yours. REST APIs, like traditional OO programming, seem to only help in a small number of situations. I've seen some really complicated things in the name of "RESTful"ness, like crazy Accept headers for different versions of the API. And like you pointed out, each developer seems to have their own idea of what REST means.

Approaching the API design from the other direction seems better. What is HTTP offering you that is better than just using a socket? It's got a request/response thing with message framing, some handy out-of-band stuff with the headers, there's HTTPS support, it works directly with browsers, and sometimes you can even get it to work through a proxy. HTTP requests are also supported pretty easily (more easily than socket stuff maybe) in most languages.

Then, using features from HTTP where they make sense can be nice (maybe some of the status codes or ETags are useful?), but throwing the whole nebulous REST framework in there without considering how well it matches the problem or how it adds to the complexity of the solution is not a good idea.