Fri, 24 Aug 2001 12:40:10 -0700
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".
> > If you have a concept that cannot be handled directly by HTTP like
> > "launchSelfDestructSequence" is it REST-ish to a) define an HTTP
> > extension header, b) put the "method" in the body (e.g. XML-RPC
> > methodName) c) define a new protocol from scratch.
> "launchSelfDestructSequence" behaviour could be a side-effect of POST
> or PUT, say POSTing a document with the correct authorization codes to
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").
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?
Take a recipe. Leave a recipe.
Python Cookbook! http://www.ActiveState.com/pythoncookbook