[psadauskas]

I don't think this is messy, this is exactly how REST is intended to work, and is beautiful. I think the most common misconception that REST is simply a way to do CRUD over HTTP, when in fact they are completely orthogonal. You can do CRUD over REST, sure, but REST is also capable of much more. That's the realization the author came to with his `/request` and `/audit` resources, and is the zen of REST. Understanding that will put HTTP to work for you, instead of fighting against it.

The reason Level 3 HATEOAS REST is hard in Backbone and most other frameworks -- both frontend and backend -- is because they have yet to obtain the same enlightenment.

[haberman]

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

[lomnakkus]

I think the parent poster should probably have emphasized the importance of HATEOAS more and the power hypertext/linking gives you. I won't spend any time on it in this comment since there are plenty of resources on the web for that, but that's really been the important thing about REST for me. It really is a wonderful thing that clients cannot even attempt invalid state transitions, and I don't think I've seen it done in any other even moderately popular RPC/IPC framework. In other frameworks/architectures for RPC/IPC all operations are just "available" all the time, but if you were to actually attempt to invoke them you'd get "operation not supported" (or the like).

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

[superdude264]

Do you know of any publicly available API that is truly RESTful (has embrace HATEOAS)?

[candu]

RunKeeper's HealthGraph returns discoverable URIs from /users:

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

[icebraining]

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?

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.

[_pmf_]

> abiding by each one gives you certain benefits

And drawbacks.

[icebraining]

It's a constraint, I think that's implicit in the term itself.

[jasonkostempski]

So much specialized hardware and software has been designed to take advantage of the protocol. REST is really just an architectural guide for using HTTP as it was intended so that those tools can, ideally, provide some efficiency. The entity being transferred isn't really what matters. It's the metadata included about the entity, it's related resources, the client and server capabilities, the explicit expression of intent and result, and all the other header info that allows those tools to do their thing.

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.

[NicoJuicy]

Thumbs up for mentioning RPC... I recently found out about that

[munro]

It's hard for me to submit to a philosophy for reasons like that it's beautiful, and that you will reach zen. Level 3 enlightenment sounds very cultish to me. :) I've dropped the notion of REST and been very happy with simple RPC, instead of contorting my mental model into resources or to align with the HTTP spec.

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/

[10098]

I used be a REST evangelist like that b̶u̶t̶ ̶t̶h̶e̶n̶ ̶I̶ ̶t̶o̶o̶k̶ ̶a̶n̶ ̶a̶r̶r̶o̶w̶ ̶t̶o̶ ̶t̶h̶e̶ ̶k̶n̶e̶e̶. Now I prefer to simply do RPC over HTTP with a JSON payload.

[dragonwriter]

> I think the most common misconception that REST is simply a way to do CRUD over HTTP, when in fact they are completely orthogonal.

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

[psadauskas]

You are correct, I could have clarified it as "CRUD of business objects in a database".

[_pmf_]

I wonder why there are so few standardizations on specifying a generalized hypertext format for HATEOAS; Atom is being mentioned whenever this aspect comes up, but I think there should be a more suitable format.