In my opinion, thinking like this how our industry goes down blind corners. To me this is how we wasted 10 years trying to XML-ify everything. Specifically, y

In my opinion, thinking like this how our industry goes down blind corners. To me this is how we wasted 10 years trying to XML-ify everything. Specifically, your arguments rest on the vague and indefinable quality of "enlightenment." I think that this use of "enlightenment" means something along the lines of "I got something to work within a thought framework that appeals to me." But if he had started with a different framework (like RPC), he could have gotten that to work too, and perhaps would be feeling the "RPC enlightenment" because all of these problems can be solved within RPC too. No one is arguing that HTTP-based APIs can only do CRUD. You can tunnel basically anything over HTTP, because ultimately the payload is just bytes. But the question is what using HTTP (and/or REST) has actually bought you, compared to competing approaches. Graydon Hoare (one of the original authors of Rust) wrote an essay about this a while ago that I really love. Unfortunately he took it off the net, but it's still available on the wayback machine: http://web.archive.org/web/20040308200432/http://www.venge.net/graydon/markup-abuse.html http://web.archive.org/web/20040308200432/http://www.venge.n... The essay is written in a very whimsical and wandering style, but the point is dead on: If you want to store or transmit a message, you can do cryptography, steganography, normalized database tables, huffman codes, elliptic curves, web pages, morse code, semaphores, java bytecode, bit-mapped images, wavelet coefficients, s-expressions, basically anything you can possibly dream up which codes for some bits. In all cases, if you're coding bits and you are using a lossless system, the *only* thing which matters is how *convenient* the encoding is. There's nothing which makes one encoding "do it better" than any other, aside from various external measurements of convenience such as size, speed of encoding, speed of decoding, hand-editability, self-consistency, commonality, etc. HTTP/REST and XML inhabit slightly different design spaces, so for HTTP/REST some of the external measurements might be a bit different. But if you are trying to argue that REST is better than competing technologies, the question is: what objective benefits does it offer, compared to those other technologies? Clearly there are benefits to REST/HTTP (being able to use a web browser as an ad-hoc UI in many cases is one), but the idea of "enlightenment" should not be a substitute for an actual compare/contrast of approaches. So yes, of course the author could find a solution to his problems that still used HTTP. The question is: once he does this, is he better off than if he had chosen a competing technology? (imagining a world where you aren't effectively forced to use HTTP to make it through firewalls).