6 ms·

REST seems like an elephant in a room with some blind folks. Everybody who touches it thinks it's something different than the next guy, and they're all describ

REST seems like an elephant in a room with some blind folks. Everybody who touches it thinks it's something different than the next guy, and they're all describing only one element of the thing. That said, I don't actually know what this elephant looks like, either, because everybody I've read on the subject seems to have only a partial understanding of it...thus, I have a partial understanding of it. If you know what the whole elephant looks like, and have good resources for what makes something actually REST, I'd be interested.

icebraining 10y ago
I suggest you go to the original source, ie, Roy Fielding: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... http://roy.gbiv.com/untangled/tag/rest http://roy.gbiv.com/untangled/tag/rest https://www.infoq.com/articles/roy-fielding-on-versioning https://www.infoq.com/articles/roy-fielding-on-versioning
- toomanythings4 10y ago
  I was going to post the same. I was lucky enough to get a few answers from Fielding himself when I first started learning this.
danpalmer 10y ago
This is the video that made it finally "click" for me. https://vimeo.com/20781278 https://vimeo.com/20781278 We don't yet have the abstractions, libraries, conventions or standards for this to work fully yet, but we're close.
ianai 10y ago
I think the above commentor got it right. You map the CRUD actions to HTTP verbs and statuses, as many of them make sense for your API, with links to further resources along the way.
jcrites 10y ago
The best way to understand REST is by example. First check out the blog post by Roy Fielding mentioned in this thread which summarizes the constraints [1]. Then let's examine how several popular restful services work versus those constraints. Here are some popular well-known services to use as examples: Google.com Amazon.com Facebook.com News.ycombinator.com. - You enter these services through the site root with no prior knowledge about the services aside from standard media types (HTML/CSS/JS) - Hypermedia is the engine of application state – meaning that you load a webpage a.k.a. resource that contains hypermedia links to other resources, and you navigate between states in the application by following those hypermedia links. For example, the hacker news homepage contains links to news articles and comment threads about them, which contains links to reply to those comments, and so on. - The application describes how to compose requests using standard media types such as web forms and JavaScript. Because the pages instruct the client about what requests to compose and to which URL, the services have control over their own name spaces which have no fixed resource names or hierarchy. I consider REST to be most easily understood as a departure to application protocol design prior to the Web, where each application and service had a unique and custom binary protocol, and a client for these services had to be reprogrammed to interact with it. REST is a set of constraints for designing services that run at Internet scale and that highly decouples clients and servers. Fielding's thesis on REST has more detail on the principles by which the REST architectural style was derived. [1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
- vfaronov 10y ago
  The big problem with using the hypertext Web as an example of REST is that there is a human operator literally driving that "engine of application state". Most API clients cannot afford to compute their state transitions on a network of 80 billion neurons.
  - Marazan 10y ago
    REST is a human driven protocol. That's why resources have a link to a description of what the resource is.
JimDabell 10y ago
> REST seems like an elephant in a room with some blind folks. Everybody who touches it thinks it's something different than the next guy, and they're all describing only one element of the thing. I don't see it that way at all. Sure, there are minor quibbles about various approaches, but you can easily place everybody into one of two camps: the ones who don't know/care about REST's technical definition, and the ones that do. The two groups largely agree about what REST is amongst members of their own group, but disagree with the other group.

icebraining 10y ago

I suggest you go to the original source, ie, Roy Fielding: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc... http://roy.gbiv.com/untangled/tag/rest http://roy.gbiv.com/untangled/tag/rest https://www.infoq.com/articles/roy-fielding-on-versioning https://www.infoq.com/articles/roy-fielding-on-versioning

toomanythings4 10y ago
I was going to post the same. I was lucky enough to get a few answers from Fielding himself when I first started learning this.

danpalmer 10y ago

This is the video that made it finally "click" for me. https://vimeo.com/20781278 https://vimeo.com/20781278 We don't yet have the abstractions, libraries, conventions or standards for this to work fully yet, but we're close.

ianai 10y ago

I think the above commentor got it right. You map the CRUD actions to HTTP verbs and statuses, as many of them make sense for your API, with links to further resources along the way.

jcrites 10y ago

The best way to understand REST is by example. First check out the blog post by Roy Fielding mentioned in this thread which summarizes the constraints [1]. Then let's examine how several popular restful services work versus those constraints. Here are some popular well-known services to use as examples: Google.com Amazon.com Facebook.com News.ycombinator.com. - You enter these services through the site root with no prior knowledge about the services aside from standard media types (HTML/CSS/JS) - Hypermedia is the engine of application state – meaning that you load a webpage a.k.a. resource that contains hypermedia links to other resources, and you navigate between states in the application by following those hypermedia links. For example, the hacker news homepage contains links to news articles and comment threads about them, which contains links to reply to those comments, and so on. - The application describes how to compose requests using standard media types such as web forms and JavaScript. Because the pages instruct the client about what requests to compose and to which URL, the services have control over their own name spaces which have no fixed resource names or hierarchy. I consider REST to be most easily understood as a departure to application protocol design prior to the Web, where each application and service had a unique and custom binary protocol, and a client for these services had to be reprogrammed to interact with it. REST is a set of constraints for designing services that run at Internet scale and that highly decouples clients and servers. Fielding's thesis on REST has more detail on the principles by which the REST architectural style was derived. [1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

vfaronov 10y ago
The big problem with using the hypertext Web as an example of REST is that there is a human operator literally driving that "engine of application state". Most API clients cannot afford to compute their state transitions on a network of 80 billion neurons.
- Marazan 10y ago
  REST is a human driven protocol. That's why resources have a link to a description of what the resource is.

JimDabell 10y ago

> REST seems like an elephant in a room with some blind folks. Everybody who touches it thinks it's something different than the next guy, and they're all describing only one element of the thing. I don't see it that way at all. Sure, there are minor quibbles about various approaches, but you can easily place everybody into one of two camps: the ones who don't know/care about REST's technical definition, and the ones that do. The two groups largely agree about what REST is amongst members of their own group, but disagree with the other group.