There is an advantage in separating "protocol" from "binding" (in this case, "HTTP binding"). While REST is typically explained as an HTTP-only protocol, this is not the only possible "binding". I've successfully designed and implemented REST-style APIs using non-HTTP based RPC methods in the past. The main benefits in REST are not coupled with using HTTP GET/POST/PUT/DELETE but with the clearly defined model of resources, operations, client/server and limitations (e.g. statelessness) to make it a simple (but powerful) model.
I agree with everything you've said. I intentionally did not separate "protocol" from "binding" in this deck. I wanted to take more of a pragmatic approach and less of an academic approach. In practice, REST is most often implemented on HTTP. Because devs can relate to HTTP, I coupled protocol and binding to keep things simple.
Agreed. The title makes it seem that the 18 slides are easily digestible when in fact, it's pretty dense and it's a slog just to even glance through them.
That's dramatic. Learning any new topic, particularly one as involved as REST, require some investment of time. Your blog post has FAR more content than my slides do. And your approach is from a "best practices" point-of-view. So the arc of our stories is necessarily different. I'm glad that blogs enable people to learn the same topic in multiple ways. It's a good for everyone. I just wish people would avoid self-promotion on top of other people's backs. =)
I have found the article I linked to be incredibly digestible for people learning REST, which is why I recommend it; regardless of the point-of-view. It's what I think is missing from your slides. You might be able to solve this in the context of an actual presentation, but taken as just the slides, it's very dense.
Also, this isn't self-promotion at all. I'm not in any way associated with that blog. I just like the content.
Different perspectives and learning styles, I suppose. I'm not trying to be argumentative, just briefly laying out my thoughts. Cheers
Yeah, as I said in my blog post this is certainly text-heavy. The more appropriate format would have been a article, but I wanted an excuse to play with SlideShare. This deck could have be thinner with more visuals if it were accompanied by audio or video as in a proper talk. But I didn't have the time to do that, so I wanted the deck to be self-contained. Just think about it as a textual blog post in slide format.
I think "horrible" is pretty strong and perhaps you meant a lighter shade of gray :-) It is unfortunate that this doesn't work on Pocket. Thanks for letting me know!
Though you can only save the presentation if you log in. Creating an account requires authorizing SlideShare to edit your LinkedIn or Facebook account.
19 comments
[ 3.4 ms ] story [ 55.8 ms ] threadFor anyone interested, this is the article I hand out when someone asks me about designing a REST API: http://www.vinaysahni.com/best-practices-for-a-pragmatic-res...
And here is the HN discussion from when it was originally posted: https://news.ycombinator.com/item?id=5819231
Also, this isn't self-promotion at all. I'm not in any way associated with that blog. I just like the content.
Different perspectives and learning styles, I suppose. I'm not trying to be argumentative, just briefly laying out my thoughts. Cheers
Thanks, surajgupta, good work.
(One side effect: I wanted to save this to Pocket to read later on a flight, but couldn't because it was slides, not HTML).
With Accept you need to parse the ";q=X" part as well.
See Accept when I access a website with Firefox: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Your REST API needs to understand this, according to these slides.
I can't GET this file.
you can "save" the presentation locally
One can use a LinkedIn account from BugMeNot (http://bugmenot.com/view/linkedin.com) to safely log into SlideShare so you can download the PDF.
(It would have been more convenient if you had just published a PDF download link alongside the SlideShare embed.)