Re: REST has too many verbs
On Tuesday 12 February 2002 00:43, Paul Prescod wrote: > > I'm working on a model for this under the name of Mercury (I have a > > periodic table fetish); the idea is quite simple at heart. A > > network-accessible object exposes a set of Interfaces, named with > > something unique like a URI; each Interface is a set of Methods (Are we > > object-oriented yet, kids?) with simple string names unique within that > > Interface (I won't say namespace out loud, but I'm thinking it). > > If you start having many of these interfaces, web service combination > becomes much more difficult. At the very least, if you want the benefits > of REST, every single interface should have a GET method. Yes and no. Each interface should, if possible, support a standard human interface method as well as domain-specified methods. The kind of architecture I'm looking at is to have a method called 'getUserInterface' that returns something like a Java class that, on the client, looks at available UI resources (command streams, GUI/menu systems, etc) through some kind of abstraction layer so that accessability and varied I/O hardware and so on are handled by the browser, and presents an interface (hopefully lazily loading other classes and resources on demand to save from loading icons when there's only textual I/O available... in Java, this can be done with the HTTP class loader, I think) and connects back to the domain-specific methods on the interface it comes from. So the Security interface would have methods to add and remove access control list entries, and a getUserInterface that just returns a URL to a standard public domain class that provides an editing interface to this. If a request is sent with an interface name of '', the default interface of the object is accessed. For a document, this would be the Document interface, not the Metadata or Security or Backup or Management or whatever interface. For something like a document, the Document interface would be provided, which has two methods: 1) getContent - returns your XML document or whatever, tagged with a MIME type 2) getUserInterface - returns a suggested viewer class for that document, but browsers are free to do their own selection based upon the MIME type and/or namespace decls in the XML or user overrides or whatever. So to conclude, I do want lots of interfaces with fine-grained selectability of particular services of an object, but also high level conventions for doing basic stuff that are shared wherever practical. Eg, most things would have a Metadata interface with an "Object getProperties (String wildcard)" method that gets all properties matching a wildcard name (so you can request individual properties if desired, or use '.*' to get the lot, or use '^[^#]*#fr$|^[^#]*$' to get all properties in French or with no #language suffix, or whatever). Name = "Alaric's Homepage" Name#fr = "Le Homepage du Alaric" <- Pardon my poor french Description = ..... LastModified = datetime(2002/02/12 12:46 GMT) Them properties need a namespace prefix, really, don't they? Perhaps they should be URIs... Building standards for those interfaces and methods and conventions and so on is something that needs to be done, yes, but I don't think it'll be any harder than establishing the same for XML-over-HTTP. > > Paul Prescod > 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format