Fri, 24 Aug 2001 16:59:52 -0400 (EDT)
> Thanks Mark. That helps alot.
> Mark Baker wrote:
> > Practically, I would expect that to perform well for only those
> > application protocols that were designed under roughly the same
> > constraints as HTTP. i.e. text based, request/response, stateless,
> > connection oriented. But this encompasses a wide array of protocols.
> > I believe all of FTP, SMTP, NNTP, IMAP, POP would be included, whereas
> > protocols like DNS and NFS wouldn't. That's just off the top of my
> > head though.
> Is anyone working on this? e.g. "Conventions for using HTTP in Email
> Clients". "Conventions for using HTTP for mail transfer".
Not to my knowledge. Right now, I'd expect this to be an uphill
battle against installed base and fear of change. But as the Web
matures with a wider variety of value-add services, the pressure will
come. At that point though, I wouldn't be surprised if it happened
accidentally. e.g. if IM first went to HTTP (its relative novelty
means less fear of change, plus the failure at the IETF to agree to
a single protocol), then started using store-and-forward as a value-add,
and before you know it, blammy, no more need for SMTP.
> > "launchSelfDestructSequence" behaviour could be a side-effect of POST
> > or PUT, say POSTing a document with the correct authorization codes to
> > /system/admin.
> Okay, but the advantges of the model are not as clear to me as in the
> GET, PUT, DELETE examples because POST's semantics are so vague (it
> might as well be called "DO").
I wouldn't exactly call them vague (at least not in the context that
you mean), but I would call them general.
I've thought about other possible names for POST; ADD and INSERT to
name two. But really, even as its described in 2616, POST is still
the best. It's certainly not "DO", because it doesn't "do" some
things. For example, it doesn't do replacement - that's what PUT's
> This brings me to another subtle issue. Do you envision that the only
> way to declare this sort of stuff is in prose text: "Here's the URL.
> Here's what you're supposed to send to it. Here's what you'll get back."
> Should there be a service description language for REST?
"Should" is too strong. "Could", for sure. Plain old "Here's the URL"
has served us pretty well so far. I don't have much of an opinion on
where something like WSDL would or wouldn't be of use, for now. If I
have anything to say about that, I'll add to the Wiki.