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

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).

Strangely, very few people (at least that I've spoken to) who are fans of REST seem to have even picked up on the HATEOAS principles. I'm guessing that their fandom is more predicated on a hatred of SOAP/XML and love of the simplicity of JSON -- which is kind of strange since HATEOAS also works beautifully for Content-type=XML over HTTP.

EDIT: An attempt to formalize the Richardson Maturity Model (L3) for REST+JSON/HTTP can be found at: http://stateless.co/hal_specification.html (I'm not affiliated with it in any way, just thought it was interesting.)

http://developer.runkeeper.com/healthgraph/users

REST isn't a technology, it's an architectural style. Regarding its benefits, they are all well specified in Fielding's thesis. REST is composed of a few constraints, and abiding by each one gives you certain benefits.

That said, I agree with you vis-à-vis the need to avoid blinders. In my opinion, there's nothing wrong with using RPC if that's the most adequate solution. What bothers me are all those new RPC-over-HTTP which people insist on calling RESTful.

And drawbacks.

HTTPs ubiquity, for better or worse, makes it about the only option for any web based tool where control from end-to-end isn't a practical option. Better protocols can be made, better hardware and software can be made to utilize them, and some have, but their reach is very limited for now. Understanding the thing we're stuck with is pretty important. Luckily, countless man hours have gone into studying the protocol and building the tools that take advantage of it. Much of that information has been shared openly. I think that's a pretty big advantage over anything else.

I personally have found zen in applying simpler concepts to software development. Such as composition over inheritance to my API design, mixing in certain aspects like content negotiation or caching, when those complexities become necessary. Or separation of concerns, making sure endpoints don't do too much, and the realization of concerns vs technology [1]. Really thinking about the notion of simplicity as describe by Rick Hickley in Simple Made Easy [2]. Or "There are only two hard problems in Computer Science: cache invalidation and naming things"--putting off caching until an endpoint becomes a problem--and not worrying if my URL structure is RESTful.

Here's an example of an API that I find beautiful [3].

[1] https://www.youtube.com/watch?v=x7cQ3mrcKaY [2] http://www.infoq.com/presentations/Simple-Made-Easy [3] https://mandrillapp.com/api/docs/

I dunno, REST maps to CRUD pretty well -- but its pretty limited when you think of it as restricted to CRUD operations against the equivalent of base tables in whatever your datastore of choice is -- its more like CRUD operations against views with arbitrarily complex rules mapping operations on the views to operations against base tables...