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