OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] ANN: REST Tutorial

[ 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 

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.


                               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  


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS