Fri, 24 Aug 2001 15:15:41 -0400 (EDT)
> What would REST advocates do about non-HTTP transports? One answer might
> be to tunnel HTTP. Another might be to try to use the semantics of
> (e.g.) SMTP "deeply" as REST advocates suggest the use of HTTP deeply.
At a conceptual level at least, I would fully expect that REST could be
used to replace all other application protocols, and that HTTP semantics
alone would suffice for most of them (some may need HTTP extensions).
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
> 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
> It is almost a no-brainer (now that I think about it!) that getStateName
> and even getStockPrice should not use RPC. But eventually you may need
> to do a state transition. You can certainly do that over POST but if
> you're still using XML method names then it seems you haven't really
> abandoned RPC (and maybe that's a good thing...maybe the two models work
> well together).
You need not use method names at all, as above.
GET/PUT/POST/DELETE; all the shared semantics a growing Web needs.