8 ms·

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

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.

dragonwriter 12y ago
> 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 12y ago
  You are correct, I could have clarified it as "CRUD of business objects in a database".
deleted 12y ago
[deleted]
munro 12y ago
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 https://www.youtube.com/watch?v=x7cQ3mrcKaY [2] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy [3] https://mandrillapp.com/api/docs/ https://mandrillapp.com/api/docs/
haberman 12y ago
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).
10098 12y ago
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.
- deleted 12y ago
  [deleted]
_pmf_ 12y ago
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.

dragonwriter 12y ago

> 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 12y ago
You are correct, I could have clarified it as "CRUD of business objects in a database".

deleted 12y ago

[deleted]

munro 12y ago

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 https://www.youtube.com/watch?v=x7cQ3mrcKaY [2] http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy [3] https://mandrillapp.com/api/docs/ https://mandrillapp.com/api/docs/

haberman 12y ago

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

10098 12y ago

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.

deleted 12y ago
[deleted]

_pmf_ 12y ago

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.