[
Lists Home |
Date Index |
Thread Index
]
On Monday 20 May 2002 19:25, Michael Kay wrote:
> > I have created a tutorial on REST. I welcome all comments,
> > suggestions, criticisms.
> >
> > HTML version: http://www.xfront.com/REST.html
>
> I finally understand. REST is just a fancy marketing name for the stuff
> we've all being doing these last n years. And there was me trying to put
> off the day I had to learn about yet another new acronym.
Similar story here: what is referred to as REST is something I encountered in
1996 or so in my own protocol design work. I looked at how HTTP worked and
extracted a few tips and tricks that would be useful for an RPC protocol.
Oddly, I have no problem with making up my own method names. There's no need
to stick with GET and PUT and POST at all, as long as you have *some*
standard methods.
Eg, under my system, you have the global ID of an RPC endpoint. There is a
compulsory method that gets provided by the system which returns the
interface definition, which is useful. There is also an 'optional but include
it unless you have a good reason not to' method which returns a user
interface. So if somebody gets that ID and drops it into their 'browser',
then it invokes that interface to get a user interface. In my model this 'UI'
was just something like a Java applet that got downloaded and then connected
to the application-specific methods.
There was also a 'method return value caching mechanism' that hid the
GET/PUT/POST distinction (in conjunction with information in the interface
declaration about which methods were idempotent and could be resubmitted
without fear of death, making a saving of efficiency in the protocol
implementation).
It also handled sessions, unlike HTTP. 'Client side state is bad!' I hear you
cry, but these 'sessions' worked pretty much like they do in a REST system...
if you just start issuing requests against an RPC endpoint there is no
session, but a method can 'open a dialogue' which then returns a new RPC
endpoint ('URL') which contains the session ID. You can email that 'URL' to
your friends and they'll be part of your 'session' too.
Another thing I learnt from HTTP that's not really specified as part of REST
(but left implied) is the concept of being able to throw together URLs with
parameters (thing.html?foo=bar). The toolkit function a server uses to 'get
its own URL' has an optional paramater, the 'persona field', which gets
slipped into the 'URL'. When methods are called on that 'URL', the contents
of the persona field come in as an implicit extra argument to the call.
This is really handy for certain things. For example, suppose one defines an
RPC interface for 'mailboxes' that have public methods to deposit mail. It
would be easy to make an RPC server that acts as a proxy to Internet mail. If
you access it with no persona set it presents a nice UI allowing you to type
in the Internet email address, and returning the 'URL' of itself with the
persona set to that email address.
If you access it with a string as the persona field, it acts as a mailbox,
but submitted mail is sent out via SMTP.
I was quite proud of all this.
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
|
