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

Re: REST has too many verbs


many verbs
"Simon St.Laurent" wrote:
> 
> After spending a few hours catching up on the REST discussion here and
> the discussions which led to it, I'm starting to wonder if REST's
> adoration of HTTP raises problems itself.

REST doesn't adore HTTP. It's the other way around. HTTP 1.1 was
designed as a protocol for REST. ;)

> My concerns about HTTP aren't that HTTP is too simple, but rather that
> HTTP itself is too complex and too extensible.  HTTP adds extension
> headers and the potential for multiple messages, as well as this array
> of GET PUT POST DELETE HEAD etc. verbs. State management is also an
> on-again off-again issue.
> 
> It seems to me, a thoroughly markup-centric person, that maybe we should
> consider verbs either implicit - the recipient should know what it wants
> to do with XYZ type of information - or explicit in the data itself.

If you do that, you make it extremely difficult to build intermediaries
like:

 * store-and-forward services
 * caches
 * firewalls
 * proxies
 * message routers
 * privacy managing intermediaries

> Either approach makes it possible to, for example, recreate a given
> state by feeding in the data that led to that state, without having to
> retain additional metadata about what the headers were, what the
> response looked like, etc.

That's the point of REST. You shouldn't have to re-create states. States
should have URIs. You should just point to the URI of the state.

> ...  Archiving a set of transactions seems a lot
> easier in this case, and I suspect the processing is actually less
> complex.

Don't know what you mean by that.

> I suspect I'm just jaded by too much exposure to Web Services debates,
> but the interesting part to me is sending XML from point to point, not
> building complex envelopes and sets of expectations around protocols.

XML is just a syntax. Surely the interesting part is in what problem you
are trying to solve and the data model you build up around that problem.
Then it becomes useful to ask which parts should go in the XML and which
in MIME.

> I'd love to see an "XMLchucker" protocol that just opens a port, sends
> the info, and maybe replies with a checksum or an error.  No more.

It'll take about ten minutes to write the RFC for that. But your
intermediaries will have no idea what is going on and won't be able to
help you.

 Paul Prescod

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.