[
Lists Home |
Date Index |
Thread Index
]
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.
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.
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. Archiving a set of transactions seems a lot
easier in this case, and I suspect the processing is actually less
complex.
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.
It feels to me like developers feel more comfortable at a greater
distance from the data, but I'm not sure that's wise practice.
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.
Maybe that'll be another bit of fun to poke at in the future.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
