In a comment
on my previous post, pwb states
"REST" still suffers mightily from no real guidance on how exactly to construct
something REST-ful. A dissertation doesn't cut it.
I guess it depends on what is meant by "real guidance". I can argue that there is
no real guidance on how to construct object oriented systems, distributed applications
or high performance data storage systems. Whether you agree or disagree with any of
those statements depends on how "official" or "canonical" one expects such guidance
to be.
If you are interested in building RESTful Web services. Here are the top 3 ways
I suggest one learn about building and designing a RESTful system.
-
Learn the Atom Publishing Protocol: The best way to figure out how
to build a RESTFul Web service is to actually use a well designed one and none is
a better example of what a RESTful Web service should be than the Atom
Publishing Protocol. For extra credit, you should also read up on Google's
GData protocol and come up with a list of pros and cons of the approaches they've
taken to extending AtomPub.
-
Read Joe Gregorio's "Restful Web" column on XML.com: Joe Gregorio
is one of the editors of RFC 5023 (the Atom Publishing protocol) and is currently employed
at Google working to make GData even more Web friendly. He started a series of articles
on XML.com on building and designing RESTFul Web
services complete with code samples. The entire list of articles can be found here but
if you don't have the time to read them all, I suggest starting with How
to Create a REST Protocol which covers the four decisions you must make
as part of the design process for your service
-
What are the URIs? [Ed note - This is actually "What are the resources?" ]
-
What's the format?
-
What methods are supported at each URI?
-
What status codes could be returned?
If you have more time I suggest following that article up with Constructing
or Traversing URIs? which contrasts client access models based on URI construction
[where clients have baked into them knowledge of the URI structure of your service]
or by URI traversal [where clients discover resources by following links either within
the primary resources your service returns or via a service document that describes
your service's end points]. Just because WSDL is a disaster doesn't mean that interface
definition languages aren't useful or that they aren't needed in RESTful applications.
Afterall even Atom has service
documents.
And finally, because I don't believe you get to design a system without being familiar
with what the code looks like and should do, I'd suggest reading Dispatching
in a REST Protocol Application which walks through what the server side code
for a particular RESTful service looks like. He even throws in some performance
optimizations at the end.
Of course, I know you're actually going to read all the articles in the series because
you're a dutiful lil' Web head and not shortcut seeker. Right? :)
-
Buy "RESTful Web Services" by Leonard Richardson, Sam Ruby, and David Heinemeier
Hansson: If you are the kind of person who prefers to have a book than
learning from "a bunch of free articles on the Internet" then RESTful
Web Services is for you. I haven't read the book but have seen it on the desks
of more co-workers than I'd care to admit and each of them favorably recommended it. Sam
Ruby, Leonard Richardson and DHH know their
stuff so you'll be learning at the feet of gurus.
To me, this seems like an abundance of resources for learning about building RESTful Web
services. Now I understand that there are some for whom until it shows up on MSDN, IBM
Developer Works or in a Gartner Report it might as well not exist. To these people
all I can say is that "It must be great to have all that free time now that you have
outsourced your thinking and business critical analysis to someone else". :)
