
How I explained REST to my wife - mrlebowski
http://tomayko.com/writings/rest-to-my-wife
======
dmor
I'm a woman, and I didn't find this patronizing or sexist, unlike some of the
commenters on both the post comments and here.

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"

~~~
kragen
> I'm a woman, and I didn't find this patronizing or sexist, unlike some of
> the commenters on both the post comments and here.

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.

~~~
mikeyur
If I'm having a conversation with someone about a topic I know absolutely
nothing about, I sound like an idiot. "What does that do?" "Who's that?"

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.

~~~
ludwig
Nice POST!

~~~
mikeyur
Great way to PUT it!

------
adi92
Feels like this guy has married ELIZA

~~~
dpcan
My guess is that this conversation happened entirely in his head. His wife was
in the room nodding and mumbling "uh huh" while he rattled off hacker-speak
for way too long. He left off his wife's last line of: "Sorry, did you say
something?"

~~~
windsurfer
Are you kidding? I'm sure his wife knows all about _polymorphic verbs_.

------
ivey
Really old, but a classic tale that needs to resurface every 6 months or so.

~~~
mrlebowski
I am not aware of anyway to make an old submitted story resurface in HN.
Probably some feature like this would be good to have?

~~~
breck
that is actually a really good idea. if you could easily peruse previous
"days" of hackernews. if an article is really worth reading once, it should be
worth reading every few months.

~~~
mikeyur
"This day in Hacker News history"

------
psadauskas
I find that the people who are against REST, or don't understand why its
neccessary, don't really understand the finer points of HTTP, either. This
post really helps describe what it is about HTTP that makes REST obvious, and
easy.

~~~
thras
Rest is obvious and fairly easy. It solves a specific set of real-world
problems.

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.

------
blogimus
When reading his intro to HTTP, I kept thinking of what Clay Shirky said,

"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:

<http://www.shirky.com/writings/evolve.html>

------
messel
As a noob to web coding, I appreciated the information although the format was
a bit dragged out. Good share mrlebowski, I look forward to more of your info
dude.

~~~
mrlebowski
Thanks, I try to share good links that I come across learning stuff at my
internship place :)

------
quan
Remind me of this article:
[http://72.249.21.88/nonintersecting/2006/11/15/the-s-
stands-...](http://72.249.21.88/nonintersecting/2006/11/15/the-s-stands-for-
simple/?year=2006&monthnum=11&day=15&name=the-s-stands-for-simple&page=)

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.

------
turtle4
So how does the machine, in these examples, request the machine understandable
representation of the resource?

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?

~~~
kragen
At the moment, generally you use GET and ask for a different Content-Type with
an Accept header, or you say something like <link rel="alternate"
type="application/rss+xml" href="foo.xml" />. In some cases you're expected to
guess the alternate URL instead, maybe based on a document somewhere else,
which is non-RESTian. However, it's pretty rare for someone to do what you
suggest, which is to use new HTTP verbs in order to get different
representations.

------
sfphotoarts
"are busy writing layers of complex specifications for doing this stuff in a
different way that isn’t nearly as useful or eloquent"

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.

~~~
tmikew
For me when I first encountered this particular post on REST a couple of years
ago it was like an ah ha moment. SOAP is just one complex layer. Struts is
another, actually a container in a container. Having messed around in J2ee
land for while this article made me realize that most folks didn't know or
didn't care what a stock J2ee container could do if one started thinking
RESTfully.

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?

~~~
jmtulloss
Mostly a "RESTful framework" just allows you to easily map verb/noun
combinations to functions. You create a noun (an object) with the standard
verbs as methods, and it does the other stuff. Pretty basic, but it makes life
easier.

------
oneplusone
I am a designer so I never really got REST, but now I do. Definitely a must
read.

~~~
grandalf
As a designer you might enjoy the way I explain REST to people:

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.

~~~
blasdel
NO. _NO._

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.

~~~
grandalf
Uh ... I didn't say guessing state, I said guessing what is behind the URL. as
in /users/greg vs /users/davis

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.

~~~
mreid
You said: "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."

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.

~~~
grandalf
ok thanks for clarifying

------
njharman
I still don't get it. There have been several things I never got or rather
they were so obvious / intuitive to me there was nothing for me to "get".
Still I spent years thinking I missed something cause so many others had such
problems with them. Pointers & recursion come to mind.

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?

~~~
kragen
Have you read Roy's dissertation?

~~~
blogimus
I read it and was surprised at how readable I found it (never mind being a
dissertation).

<http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>

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.

------
villiros
Here's how I would explain REST to a wife:

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.

------
chanux
How this can be posted again?

<http://searchyc.com/How+I+explained+REST+to+my+wife>

------
duncanj
It still bothers me that web browsers don't really "do" REST without
Javascript.

------
keefe
The title should read "how I explained REST to my trophy wife". Also, all the
structured data stuff doesn't really belong in a discussion of REST, imho.
SemTech researchers have been studying this problem for a long time, came up
with RDF etc. Tim Berners-Lee was also you know, involved in those HTTP
efforts, you can watch him discuss this topic here
<http://blog.ted.com/2009/03/tim_berners_lee_web.php> . Not impressed with
this REST article.

