GData and INVOKE

Don Box's Spoutlet

Syndication

RichB pointed to the GData protocol as a way to make PUT and DELETE work.

GData does more or less what every other HTTP-based app does.

It uses GET for queries and POST for side-effect-bearing operations of all sort (e.g., creating, updating, deleting).

Ratber than put the name of the operation inside the entity body of the POST, they coin a new HTTP header for the request to tunnel it down to the server.

Do many (any?) HTTP intermediaries do reasonable stuff with this vis-a-vis cache control?

Seems awfully reminicent of the approach we took with dreaded SOAPAction HTTP header in SOAP/1.1 - tunnel new semantics through the virtually semantic-free POST operation (which often seems to wind up serving as INVOKE as much as anything else).

The only difference I can see is that they've put two actions in there so far (PUT and DELETE).

 


Posted Jan 13 2007, 06:38 PM by don-box

Comments

RichB wrote re: GData and INVOKE
on 01-14-2007 10:11 AM
That HTTP header is optional. It's a fallback header for when firewalls/proxy servers between client and server prevent standard HTTP PUT AND HTTP DELETE from getting through.

Your commentary sounds like you expect them to add more actions. I very much doubt they will. They have all the actions they need. Create, Read, Update, Delete. They're all the verbs you need.

So you see, SoapAction is moving the meaning of the operation up a level into the protocol. The REST-style interaction of GData doesn't encode this sort of information into the protocol. It is presumed you know what you are manipulating given the endpoint you are accessing.

GData is about manipulating lists. So you add a new item to a list, update a number of items from a list, delete an item from a list and read and list. These are much more basic forms of data manipulation than SOAP tried to solve. But as the world re-learns the power of lists (LINQ anyone?), we're also relearning that data manipulation in a client-server scenario can be handled in the same way.
Don Box wrote re: GData and INVOKE
on 01-14-2007 10:25 AM
Rich,

I have no idea whether Google will or won't add more actions to their "sub-method" HTTP header.

I agree that if the current approach looks like a pure "tunnel HiREST through LoREST" which is a pragmatic nod to the fact that lots of the web only really supports LoREST.

DB
Stefan Tilkov wrote re: GData and INVOKE
on 01-16-2007 6:51 AM
The "lots of the web" that only really supports LoREST seems to be HTML Forms. Firewalls that block PUT and DELETE do so for a reason, even if that reason may be stupidity. I'm not sure the Web wouldn't be better off without workarounds such as the GData one.

In any case, I believe there's a huge difference between their workaround and the SOAP approach - the GData folks started out RESTfully and added this workaround afterwards, not as part of the original architecture.
Don Box wrote re: GData and INVOKE
on 01-16-2007 2:11 PM
Stefan,

I agree the premises of SOAPACtion vs the GData workaround are different.

What I'm observing is that pragmatically, the GET/POST combo is the underlying reality and that multiple interpretations get layered above it.

To me, that point is huge, no matter which side of the "uniform interface vs. arbitrary invocation" argument you take.
dbox wrote GData 和 INVOKE
on 02-15-2007 1:17 AM
RichB ???GData??,???????????PUT?DLETE?????
GData??????????????HTTP????????

Add a Comment

(required)  
(optional)
(required)  
Remember Me?