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

Re: REST has too many verbs

• To: xml-dev@l...
• Subject: Re: REST has too many verbs
• From: "Simon St.Laurent" <simonstl@s...>
• Date: 11 Feb 2002 14:11:22 -0500
• In-reply-to: <3C68021A.98D28BF1@p...>
• References: <1013451210.845.127.camel@l...> <3C68021A.98D28BF1@p...>

On Mon, 2002-02-11 at 12:40, Paul Prescod wrote:
> REST doesn't adore HTTP. It's the other way around. HTTP 1.1 was
> designed as a protocol for REST. ;)

HTTP 1.1 was built as a protocol for HyperText Transfer, to the best of
my recollection.  It's hardly a monument to architectural simplicity,
though it does an excellent job of transferring and storing information
built around the notions in HTML.

> 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

I don't believe that to be a true statement.  You can't simply reuse
(or, as some have noted, abuse) existing implementations of those
systems, but it hardly rules them out.  

It does mean a shift from working with metadata to working with data,
which may be substantial, but it's hardly the end of networking as we
know it.

> > 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.

And if that state represents the results of a few thousand individual
messages, how exactly do I recreate it in the event of a failure?

URIs make nice destinations.  That's about as much as they're good for
without metaphysical metadata hocus-pocus.  States are things as they
are, not things as they are labeled.

> > ...  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.

It means that the messages are all you need to keep should you need an
archive for backup or regulatory purposes.  From a legal standpoint,
it's nice to know how the contents of your data store came to be, not
just how they are today.

> 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.

Sure, XML is just a syntax.  That's what makes it so flexibly usable for
this kind of application.  I'm perfectly happy to work with MIME-based
systems because they're what we have right now.  I'm not willing to
concede that MIME approaches are a good idea to continue supporting
moving forward, however.
 
> > 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.

They won't today, but they may someday.  I don't believe this idea is
inherently any worse than that of reusing HTTP in these contexts.

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com

• Follow-Ups:
  • Re: REST has too many verbs
    • From: Paul Prescod <paul@p...>
  • Re: REST has too many verbs
    • From: Gavin Thomas Nicol <gtn@r...>

• References:
  • REST has too many verbs
    • From: "Simon St.Laurent" <simonstl@s...>
  • Re: REST has too many verbs
    • From: Paul Prescod <paul@p...>

• Prev by Date: Re: WSIO- With Name
• Next by Date: Re: REST has too many verbs
• Previous by thread: Re: REST has too many verbs
• Next by thread: Re: REST has too many verbs
• Index(es):
  • Date
  • Thread