I've gotten much more into web development in the past couple years, and this post reminds me of a handful of precious conversations I've had with incredibly smart people who took the time to bring together concretes and abstractions together in a way I could understand. I think this is a good post to share with other no-so-technical-people who you wish understood more about what you do.
Maybe I should write a post on "How I Explained Marketing to My Husband"
I think his wife complained (in the comments) that she thought it made her sound stupid. Otherwise I agree, and I look forward to reading your post about marketing.
Also, this 'conversation' was very 1-sided because the author was trying to prove a point. It really didn't matter what the wife said throughout but it let him explain further and use some real world examples for those who may not GET it.
When I write conversations down it's hard to capture the spirit of the give and take. My straight-line write-down-the-meat approach always ends up devaluing the questions and ideas raised by others. My goal is to record what I learned from them, and I often come off sounding self-obsessed. I think it's an occupational hazard: all of us emphasize what we say in our own minds. Writing down conversations just uncomfortably highlights that fact.
On the other hand, that list of problems is a pretty small part of web application design. Solutions other than REST seem to work just as well.
"HTTP and HTML are the Whoopee Cushion and Joy Buzzer of Internet protocols, only comprehensible as elaborate practical jokes."
Read further if you're not familiar with this quote:
This past summer I signed up for a Java Web Service course, which made my life a living hell trying to get SOAP, WSDL, and WS-* working. It also makes me appreciate REST a lot more.
If the 'concept' is http://www.example.com/book/123, from this explanation, then there should be a way to get different representations of that via different verbs, right?
I guess this is where it always falls down for me, because there isn't a consistent way that all machine readable representations are flagged. Rather, we usually seem to define different URLs via extensions, for example, to define the different representations, which from this explanation seem like they should be reserved for different 'nouns' or 'concepts'.
Am I misunderstanding, or is that just the state of where we are at? And are there any plans to define those new 'verbs' at some point?
What is that supposed to mean. HTTP is such a simple protocol that people need to invent technologies atop it because on its own it can't do much. lack of state, for example, so people came up with cookies and sessions and so on. These were necessary and an integral part of the web's evolution from the days back in the early 90's when people had 'home pages' of pictures of their cat.
I personally found the article badly written, overly long and full of passive aggressive attacks at what the web has become.
Then we built a whole enterprise web application using just a stock J2ee container and RESTful style thinking. How much simpler! No extra frameworks to learn. The UI became completely decoupled from the services. The services are completely decoupled from the J2ee container, naturally. All the container does is resolve the nouns to a service name and give a call back to the appropriate verb method, doGet, doPut, doDelete.
In fairness we are not 100% RESTful there is some legacy stuff that relies on the session. However having done a few SOAP/WSDL services and tons of Struts actions or Spring "injections" I must say that REST is in my opinion a much cleaner way to code for web apps. Whenever I hear about some implementation needing a SOAP/WSDL service I run the other way as fast as possible. I won't even debate folks about it anymore, I just refuse to work on all that complexity.
As an aside I have seen here and there some frameworks the purport to use REST. I don't really get this. Why would somebody need and additional framework to make something RESTful? I have done it with J2ee and just plain Apache. I believe the web itself to be the framework, I could be way off in my thinking though, it wouldn't be the first time. Anybody have any clues about what a RESTful framework is for?
He's referring to SOAP there I'm sure. And he's right. SOAP is awful.
Think of the URL as part of the User Interface. REST offers conventions that make it easy to guess the URL of what you are looking for, just as you would guess where to click/navigate to get it.
I realize this only covers one aspect of REST, but I like it because I think the idea of an address as a resource which has a certain appearance (its URL) is quite powerful.
edit: I realize that rest could just as easily use meaningless identifiers, but it is often the case that meaningful identifiers are used such that the user can GET desired items by guessing the URL.
REST is absolutely not about being able to guess URLs -- it's about never having to guess a URL. Repeat after me: Hypertext. As. The. Engine. Of. Application. State.
Clean, meaningful, organized / structured URLs are unrelated to REST, and their presence tends to lead to the predominant anti-pattern of 'API Specifications'. Leave that bullshit in SOAP's failure pile.
rather than /u.exe?23q4234q34q34234234asdfa&query=true&xml=false&screen=home
The point I was trying to make is that with REST, URLs have meaning in and of themselves, not dependent on the presence/absence of a variety of other aspects of state embodied in the URL... The protocol (and REST verbs) is how you add that additional meaning... and a different URL thus means something different. Hence, for some universe of items, if one has an obvious meaning, the rest should.
If you are using the protocol in the right way then your resource will not change depending on which verb you are using.
In your earlier comment it does seem as though you are talking about guessing the URL.
What the other comment was alluding to with "Hypertext. As. The. Engine. Of. Application. State." (or HATEOAS, one of the main principles of REST) is that your application should never have to guess a URL. The possible URLs your application can next GET/POST/PUT/DELETE to should be given in the response to the last action it took.
There is nothing in the original description of REST that says anything about URLs being human readable. That's a pleasant side-effect of a sensible design but isn't the main aim.
As the original post describes, the importance of REST is to make simpler for machines (not humans) to manipulate services on the web.
You should probably read a bit more about the principles of REST before confusing people with your own interpretation of what you think it is.
edit: mistakenly thought HN understood markdown.
edit: mistakenly thought HN understood HTML.
In practice this can increase the amount of requests required to get at the information you want, and also the size of each request, as it must then include information about the actions that can be taken on the resource. It could be argued that this constraint is more for the benefit of systems or programs that need to interact with the API without knowing anything but the initial URL, and not necessarily a programmer who can work these things out. owever, if a REST API uses this constraint, and application developers follow it, deep changes can be made to the URL structure of the API without breaking the applications that use it.
There just doesn't seem that much to REST (that's not a bad thing). Lot's of hype, fud, misunderstanding built up around REST. Arguments over the proper way to apply REST to HTTP/Web. But, REST itself seems sort of duh, how else would you do it?
It's not magical rocket science, right?
What is also really good is Richardson and Ruby's "RESTful Web Services" book. They coined the term "Resource Oriented Architecture" to describe a specific REST design implementation and to side-step a religious war on what is and is not REST.
It's a made-up pile of bollox. It stands for "and now I'm going to refer to meaningless pseudo-science in an attempt to confuse you and bill more money to the project."
On second though, that probably explains why I don't have a wife.
Wife: Who is "Roy Fielding"?
Me: Some guy. He’s smart.
Wife: Oh? What did he do?
Me: He helped write the first web servers and then did a ton of research explaining why the web works the way it does. His name is on the specification for the protocol that is used to get pages from servers to your browser.
Wife: Oh, sorry, I thought he was in that movie with Jennifer Aniston.
Me: The web is pretty amazing really. And the funny thing is that it’s all very undervalued. The protocol I was talking about, HTTP, it’s capable of all sorts of neat stuff that people ignore for some reason.
Wife: Can you please stop it. I've been trying to catch the finale of ER for the longest time.
Me: But HTTP is really simple to explain.
Wife: Some other time honey, not now.
Actually, I suspect it'd end with a different line 3: "So what do you want for dinner?" or "When are you going to put up the shelves?" LOL.
As an adult, I personally would prefer if you explained something to me and let me be the judge of how smart and amazing everybody is.
I don't know anything about wine, and I really appreciate being told, "this is made my ____, they are super famous for ____".
then I can judge if I like it or not, regardless of how famous/old it is.
I also really like hearing other people's opinions and interacting with their excitement over "their thing" so ... to each their own I suppose.