[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: HTTPEctomy considered bad (was RE: RE: MSthinks

• To: "'Paul Prescod'" <paul@p...>, xml-dev@l...
• Subject: RE: HTTPEctomy considered bad (was RE: RE: MSthinks HTTP Needs Replacing???)
• From: Michael Brennan <Michael_Brennan@A...>
• Date: Thu, 28 Feb 2002 15:43:54 -0800

> From: Paul Prescod [mailto:paul@p...]

<snip/>

> I agree 100%. But isn't that what XML buys you? 

Sure. If the info you need is there in the XML. I don't want to overstate
the case, here. This isn't a huge technical challenge. All you need to do is
retain the relevant protocol info with the message (e.g. HTTP method, URI,
and headers pertinent to message processing). But for the harried IT
developer who is not going to spend time becoming an HTTP expert, using an
approach that explicitly places all the info they need for message
processing in the message body has some appeal. Countering that appeal
requires a protocol agnostic model that intelligently leverages the
protocols used without requiring the user to become a protocol expert. The
notion of a "resource not found" is generic; status code 404 is not.
Accepting a message for later processing is a pretty generic notion;
returning status code 202 is not. (I'll confess that I've never thought to
do the latter until I saw this mentioned on the rest-discuss list by
someone. Nowadays I'm spending some time combing through the HTTP spec
looking for what else I've overlooked that I could be leveraging. You'll
never get the average IT developer to spend time doing that, though.)

Maybe throwing some variant of XMTP [1] into the mix that can offer a
storage format for messages that captures the relevant info from the
protocol layer in a defined way can help here, too. The format could have a
generalized vocabulary for certain metadata properties that can be mapped in
a straightforward fashion to an HTTP method and headers, but could be mapped
to other representations for other protocols. It seems to me that this not
only offers a protocol agnostic model for the developer to work with, but
one that offers richer constructs to work with because it fully leverages
the protocol. The latter is what could offer some appeal to developers who
currently find the SOAP/WSDL marketing pitch attractive. (At least, it is
the latter that has clicked with me and got me interested in this.)

I'm thinking this would be useful. Don't get me wrong, though. I'm not
defending the protocol agnosticism of the current SOAP/WSDL approach. On the
contrary, I'm just brainstorming on how to make a more REST-ful model
approachable to IT developers who will never take the time to become HTTP
protocol experts.

[1] http://www.openhealth.org/xmtp/

• Prev by Date: Re: MS thinks HTTP Needs Replacing???
• Next by Date: Re: Check out the pipeline submission
• Previous by thread: Check out the pipeline submission
• Next by thread: ANNOUNCE: Ruple (XML Spaces) Alpha Version 2
• Index(es):
  • Date
  • Thread