0xDECAFBAD

It's all spinning wheels and self-doubt until the first pot of coffee.

REST: What's it good for? Part Deux

Chris Heschong writes: Ken ?MacLeod notes that, in regards to REST, "the only thing holding us back is a marshalling standard." I'd be a lot happier with REST implementations if this were the case.

(Whew, I think I need a convention for quoting quoters. Maybe a new language. I seem to remember hearing on the Todd Mundt Show that the Turkish language has a facility for specifying whether something you're saying originates with you, or whether you heard it from someone else...)

Anyway, since Ken ?MacLeod had taken the time to respond in some detail to a post I made asking about REST not too long ago, I thought I should come back around to it.

So I think my first confusion was with marshalling. This is why I like XML-RPC: I don't worry about much. As a client, I give it a URL and a method name, and then throw a pile of parameters for the method at it. As a server-side method, the server gives me parameters when it calls me, and I throw back a return value. The server takes care of turning the XML into my arguments, and my return value to XML.

In all the languages I've worked with it in (ie. Perl, Python, ?UserTalk, and AppleScript), this works conveniently well. I never actually pay much attention to the XML in XML-RPC. So, I was very confused in reading a few things about REST and not seeing much mention of this, other than along the lines of "Oh, well, you could go ahead and use XML-RPC libraries to build messages if you wanted to." Which begged the question for me: Why not just go the whole hog and use XML-RPC? (Or SOAP, for that matter, but that's another holy war I'm avoiding for the present context.)

Okay, so REST isn't about marshalling parameters. Then what is it about? Well, I think a bit more reading and Ken's response to me have helped illuminate me a bit.

The REST point seems to me to be that all operations being attempted by Web Services can be distilled into a few actions: retrieve, create, update, and delete. REST says that these fundamentals are already defined as GET, POST, PUT, and DELETE, respectively. I think. Is this right?

So, I apply these verbs to URI nouns. To concretize the concept: I recently wrote & exposed an XML-RPC API to a scorekeeping component on one of our promotions. Some of the methods of this API were along the lines of int points.get_points(string email), points.award_points(string email, int points), and points.create_points_account(string email). To make myself a new account I'd call points.create_points_account("deus_x@pobox.com") and then points.award_points("deus_x@pobox.com", 100) to drop myself some points in the scoreboard. Then, I would do points.get_points("deus_x@pobox.com") to check my score.

I'm afraid this example is too simple. Jon Udell wrote that he wanted to see the "stock quote example" retired for being too simplistic to stress the technology in mental experiments. Hmm. Oh well, let's see where it goes.

So, if I were to RESTify the above example, would the sequence of things be like a POST, PUT, and GET, all to a URL that looks something like:

http://myhost/promotion/players/deus_x@pobox.com/points

Whereas POST does the account creation, PUT updates the points, and GET of course grabs the points total?

Okay, maybe POST needs to post to .../players/deus_x@pobox.com with a request body specifying "points", to create the new URI? The request body of the PUT should contain a points value -- positive for award, negative for debit? And if the thing needed more complex data, I could use something like XML-RPC to encode a data structure as arguments, or as Chris Heschong wrote, use WDDX?

Do I get it? Hmm... okay, have to run to a meeting, but I wanted to post this and see if anyone could give me feedback on my understanding. I think I see how, if all resources are manipulatable in this manner, one could envision a more abstracted and uniform interface on web resources than a pile of published web services APIs. But... can it really be that abstracted?

Hmm.

shortname=oooabg

Archived Comments

  • pb
    Why not POST/GET requests with key=value pairs as a response. Done. Forget the PUT and DELETE. You're just making a function call. Forget XML formatted response since so few environments come with XML parsing. The average function call returns so little data that key=value pairs are more than adequate. And everyone already knows how to do this stuff.
  • Christopher Heschong
    pb, how do you represent arrays? Or multi-dimensional arrays? Or note that something is an integer instead of a string?
  • Mark Baker
    deus_x, that's pretty much exactly right. The only clarification I'd make is that you might POST an email address (in plain text, or application/x-www-form-urlencoded, or XML if you want) to http://myhost/promotion/players in order to create a new player. That POST could return a HTTP 201 response with the Location header set to the URI of that new player (if it succeeded). MB
  • l.m.orchard
    pb: Well, that's exactly how I did things with flash games-- POST/GET requests with key/value pairs which responded with key/value pairs. Like Christopher says, this started to fall apart when I needed richer data structures. As for REST, it seems that their idea is to not make function calls. What you do with REST is to treat URIs more like database resources, on which you perform SELECT (GET), INSERT (POST), UPDATE (PUT) and DELETE (DELETE). So instead of calling an award_points method on my player object, I UPDATE (PUT) points on the points resource of my player (represented by URI).