RESTful Web Services: the book

RESTful Web Services is a newly published book that should be a great help in giving people an overview of how to build web services that work with the architecture of the Web. The authors of the book are I believe serious RESTafarians. They hang out (virtually) on the yahoo REST discuss newsgroup. So I know ahead of time that they will most likely never fail on the REST side of things. Such a book should therefore be a great help for people desiring to develop web services.

As an aside, I am currently reading it online via Safari Books, which is a really useful service, especially for people like me who are always traveling and don't have space to carry wads of paper around the world. As I have been intimately involved in this area for a while - I read Roy Fielding's thesis in 2004, and it immediately made sense of my intuitions - I am skipping through the book from chapter to chapter as my interests guide me, using the search tool when needed. As this is an important book, I will write up my comments here in a number of posts as I work my way through it.

What of course is missing in Roy's thesis, which is a high level abstract description of an architectural style, are practical examples, which is what this book sets out to provide. The advantage of Roy's level of abstraction is that it permitted him to make some very important points without loosing himself in arbitrary implementation debates. Many implementations can fit his architectural style. That is the power of speaking at the right level of abstraction: it permits one to say something well, in such a way that it can withstand the test of time. Developers of course want to see how an abstract theory applies to their everyday work, and so a cook book such as "RESTful Web Services" is going to appeal to them. The danger is that by stepping closer to implementation details, certain choices are made that turn out to be in fact arbitrary, ill conceived, non optimal or incomplete. The risk is well worth taking if it can help people find their way around more easily in a sea of standards. This is where the rubber hits the road.

Right from the beginning the authors, Sam Ruby and Leonard Richardson coin the phrase "Resource Oriented Architecture".

Why come up with a new term, Resource-Oriented Architecture? Why not just say REST? Well, I do say REST, on the cover of this book, and I hold that everything in the Resource-Oriented Architecture is also RESTful. But REST is not an architecture: it's a set of design criteria. You can say that one architecture meets those criteria better than another, but there is no one "REST architecture."

The emphasis on Resources is I agree with them fundamental. Their chapter 4 does a very good job of showing why. URIs name Resources. URLs in particular name Resources that can return representations in well defined ways. REST stands for "Representation of State Transfer", and the representations transferred are the representations of resources identified by URLs. The whole thing fits like a glove.

Except that where there is a glove, there are two, one for each hand. And they are missing the other glove, so to speak. And the lack is glaringly obvious. Just as important as Roy Fielding's work, just as abstract, and developed by some of the best minds on the web, even in the world, is RDF, which stands for Resource Description Framework. I emphasize the "Resource" in RDF because for someone writing a book on Resource Oriented Architecture, to have only three short mentions of the framework for describing resources standardized by non less that the World Wide Web Consortium is just ... flabbergasting. Ignoring this work is like trying to walk around on one leg. It is possible. But it is difficult. And certainly a big waste of energy, time and money. Of course since what they are proposing is so much better than what may have gone on previously, which seems akin to trying to walk around on a gloveless hand, it may not immediately be obvious what is missing. I shall try to make this clear in the series of notes.

Just as REST is very simple, so is RDF. It is easiest to describe something on the web if you have a URL for it. If you want to say something about it, that it relates to something else for example, or that it has a certain property, you need to specify which property it has. Since a property is a thing, it too is easiest to speak about if it has a URL. So once you have identified the property in the global namespace you want to say what its value is, you need to specify what the value of that property is, which can be a string or another object. That's RDF for you. It's so simple I am able to explain it to people in bars within a minute. Here is an example, which says that my name is Henry:

<> <> "Henry Story" .

Click on the URLs and you will GET their meaning. Since resources can return any number of representations, different user agents can get the representation they prefer. For the name relation you will get an html representation back if you are requesting it from a browser. With this system you can describe the world. We know this since it is simply a generalization of the system found in relational databases, where instead of identifying things with table dependent primary keys, we identify them with URIs.

So RDF, just as REST, is at its base very easy to understand and furthermore the two are complementary. Even though REST is simple, it nevertheless needs a book such as "RESTful web services" to help make it practical. There are many dispersed standards out there which this books helps bring together. It would have been a great book if it had not missed out the other half of the equation. Luckily this should be easy to fix. And I will do so in the following notes, showing how RDF can help you become even more efficient in establishing your web services. Can it really be even easier? Yes. And furthermore without contradicting what this book says.


While I have respect for RDF, I believe that Google's statistical models are more likely to yield generally positive results to most people. RDF seems like bringing the mountain to Mohammed, whereas statistical analysis of "the mountain" of the web moves the burden of semantics to the silicon - not the author. Horses for courses. Whatever works.

Posted by Kevin on June 07, 2007 at 03:37 AM CEST #

In some ways I agree. While reading the REST dissertation fit in well with lessons I'd learnt the hard way as a web developer, and having done so went on to inform how I think about the web immensely, it was not my general web development background that led to my reading it, but rather I came across it due to a period of interest in RDF. On the other hand, while the two can indeed fit hand-in-glove, there are definite advantages in learning the two separately or in being able to be quite expert in one while remaining ignorant of the other. Particularly from the REST point of view (you can do REST without doing RDF, though doing RDF will mean doing web requests and/or responses at least 95% of the time so the inverse is not as strong). There is also still a bit of an evangelical burden on advocates of both REST and RDF, with both still having vocal detractors. There is therefore a balance between allowing them to build on each others successes when it comes to convincing people, and in tarring them both with the same brush in the minds of those who are sceptical of one or the other. Finally, RDF is a pretty big topic, I had a period of quite strong interest in it but now find myself completely lost whenever I glance over what the RDF people are currently talking about (as opposed to just mostly lost which I used to be). As such one can either mention it in passing or devote many chapters to it, but one can't do it justice in say one chapter. I think more than a handful of sentences on RDF would be a mistake in a book focusing on REST published this year.

Posted by Jon Hanna on June 07, 2007 at 04:11 AM CEST #

[Trackback] Henry Story: So RDF, just as REST, is at its base very easy to understand and furthermore the two are complementary. Even though REST is simple, it nevertheless needs a book such as “RESTful web services” to help make it practical. There ar...

Posted by Stefan Tilkov's Random Stuff on June 07, 2007 at 04:39 AM CEST #

And yet RDF is not simple at all. Taking your foaf card I'm look at the "knows" collection:

 <same as

After transforming it into triples I can see that it creates

#card knows <newsymbol>
<newsymbol> hastype ...
<newsymbol sameas ...
<newsymbol has name ...

It's confusing that the three sybling nodes are predecates of the same anonymous item. After looking at your super simple example you'd expect something like:

card#me knows http://.../foaf.rdf#me

The name, type, and other items are in the other foaf doc. in rdf we repeat ourselves a lot.

One thing I have found is that converting rdf into triples is helpfull in getting that simple feeling back. I'm still confused as to why we need rdfs subclass and then owl subclasses.

Taylor [ markup added by bblfish ]

Posted by Taylor on June 07, 2007 at 01:51 PM CEST #

Taylor, thanks for the comment. That was just me being sloppy. If you get the rdf xml representation you get much better rdf without all those useless identity statements.
It turns out that cwm removes anonymous nodes when it has N3 written in the form
xxx relation [ = uri; 
              other:rel "something";
             ] .  
which is what I wanted all along. So I just rewrote the N3 which generates the rdf+xml and regenerated the rdf. If you now get the N3 you get a nicely readable format too.
curl -H 'Accept: text/rdf+n3' -L

Posted by Henry Story on June 07, 2007 at 03:04 PM CEST #

"While I have respect for RDF, I believe that Google's statistical models are more likely to yield generally positive results to most people." You need both, probably layering RDF/interlingua on top of statistical systems (and some straight up guessing as to meaning) to build hybrid systems. The RDF model theory even leaves room for that layering; unfortunately the semweb program hit similar problems to GOFAI by applying the semantic cart before the statistical horse. Modern machine learning and robotics has done a lot to rectify that; I'd love to see more semweb researchers focus on hybrid techniques (and they might have to anyway to deal with large datasets)

Posted by Bill de hOra on June 07, 2007 at 05:15 PM CEST #

I've been talking about REST and RDF as complementary for sometime now. And yes in essence they are both very simple. I even did a presentation on the topic, the PPT is available here

Posted by Alex James on June 07, 2007 at 07:06 PM CEST #

hello, i am a newbie regarding web services, REST and RDF. I'm still trying to understand how everything adds up...but i have a few questions, can RDF be used as a substitute for WSDL in a RESTful service? , can we use RDF to describe interfaces in RESTfull services? if this is possible, then can we use RESTful services for SOA style systems integration?

Posted by Roger Marin on July 31, 2007 at 10:16 AM CEST #

Hi Roger, you asked
can RDF be used as a substitute for WSDL in a RESTful service
My answer is a tentative yes, but one has to think very differently about the pieces. Think Web Architecture: every URI points to a resource which can return a representation on an HTTP GET, describing it. An RDF representation would describe that object in some way, usually by relating it to strings, classes (URIs) or other resources (URIs). The description of the object/resource is therefore a set of relations, usually thought of as a graph, which can be mapped to an object graph using a library such as so(m)mer. There is no need for a WSDL. Every resource describes itself.

I wrote up an example in a recent post "RESTful Semantic Web Services". The first part of that post I am very confident of. The second part, relating to SPARQL queries is a research idea, so please be lenient :-)

There is a well known way to relate SOAP and RDF via OWL-S. But this requires people to know both RDF and SOAP, which does not make things simple enough in my opinion. The above article I think points to a way in which one can avoid SOAP completely, but that is an open research question. Have a look at that blog post, and let me know what you think.

Posted by Henry Story on July 31, 2007 at 12:00 PM CEST #

"It would have been a great book if it had not missed out the other half of the equation. Luckily this should be easy to fix. And I will do so in the following notes, showing how RDF can help you become even more efficient in establishing your web services."

I perused many other posts of your blog, but I was unable to find where you did the mentioned fix. Could you point the exact place or, alternatively, elaborate on this subject?

Posted by Marcio Faria on November 07, 2009 at 10:50 AM CET #

Post a Comment:
Comments are closed for this entry.



« July 2016