[
Lists Home |
Date Index |
Thread Index
]
"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
|
