An Illustrative Example
UDDI is an example of a web service that could be made much more robust as a resource-centric web service. I'm not discussing the philosophical issues of UDDI's role in the web services world but the very concrete issue of how to get information into and out of it. These arguments will apply to most of the web services in existence, including stock quote services, airplane reservations systems, and so forth.
UDDI has a concept of a businessEntity representing a corporation. Businesses are identified by UUIDs. The Web-centric way to do this would have been to identify them by URIs. The simplest way to do this would be to make a businessEntity an XML document addressable at a URI like"http://www.uddi.org/businessEntity/ibm.com" or perhaps "http://www.uddi.org/getbusinessEntity?ibm.com". The difference between these two is subtle and does not have many technical implications so let's not worry about it.
You can think of "http://www.uddi.org/businessEntity" as a directory with files in it or a web service pulling data from a database. A wonderful feature of the Web is that there is no way to tell which it is just from looking at the URI. That is "loose coupling" in action.
Let's consider the implications of using HTTP-based URIs instead of UUIDs for business entities:
- Anybody wanting to inspect that business entity would merely point their browser at that URI and look at the businessEntity record. An HTML version could be served to legacy browsers and the XML version to newer ones.
- Anybody wanting to reference the businessEntity (in another web service or a document) could just use the URI.
- Anybody wanting to incorporate the referenced information into another XML document could use an XLink, XPointer or XInclude.
- Anybody wanting a permanent copy of the record could use a command line tool like "wget" or do a "Save As" from the browser.
- Any XSLT stylesheet could fetch the resource dynamically to combine it with others in a transformation.
- Access to the businessEntity could be controlled using standard HTTP authentication and access control mechanisms
- Metadata could be associated with the businessEntity using RDF
- Any client-side application (whether browser-based or not) could fetch the data without special SOAP libraries.
- Two business entities could represent their merger by using a standard HTTP redirect from one businessEntity to another.
- Editing and analysis tools like Excel, XMetaL, Word and Emacs could import XML from the URI directly using HTTP. They could write back to it using WebDAV.
- UUIDs or other forms of location-independent addresses could still be assigned as an extra level of abstraction as demonstrated at purl.org.
The current UDDI API has a method called get_businessDetail. Under an address-centric model, that method would become entirely redundant and could thus be removed from the API. UDDI has several get_ methods that operate on data objects such as tModels and business services. These data objects could all be represented by logical XML documents and the methods could be removed. Note how we have substantially simplified the user's access to UDDI information. At the same time we've elevated the importance of XML and XML modeling in the UUDI system.
Business entities are not the only things in UDDI that should be identified by URI-addressable XML resources rather than SOAP APIs. In fact all of the data in a UDDI database could be represented this way.
Summary: Resources (data objects) are like children. They need to have names if they are to participate in society.
Remember Metcalfe's law about the value of connectivity on a network? If you organized a web service around URIs, then that service can automatically integrate with other web services through links. A UDDI entry in one registry can easily point to a UDDI entry in another. In fact, businesses could maintain their corporate information on their own site and merely "register" it with UDDI when it changes. Resource-centric web services are intrinsically easy to federate.
Elements in a single UDDI registry can only (with a few exceptions) refer to each other. They cannot refer to objects elsewhere on the Web (for instance in other UDDI repositories) or vice versa. A URI-centric solution would unify these data domains in the same way that the phone number system unifies telephones.
Because the businessEntity documents are XML, it is relatively easy to add elements, attributes, or other namespaces to the format. XML is an intrinsically extensible data representation. It is also easy to extend the protocol by adding specialized HTTP headers or even (in rare cases) new HTTP methods.
Performance of web services will be an important issue. Any resource representation retrieved from a GET-based URI can be cached. It can be cached in a cache server in front of the server, in an intermediate provided by an ISP, at a corporate firewall, or on the client computer. Caching is built into HTTP. SOAP get_businessDetail messages are not cached by any existing technology. There are a variety of other performance enhancements possible with the REST architecture.
UDDI has other methods for working with businessEntities. One is delete_business. HTTP already has a DELETE method. Therefore this method would be redundant in the REST model. Instead of doing a UDDI SOAP-RPC specific delete you could do an HTTP delete. This would have the benefit of being compatible with tools that know how to do HTTP deletes, like the Windows 2000 explorer and MacOS X finder. In theory, businesses could delete portions of their own records (perhaps obsolete branch plant addresses) by merely hitting the "delete" key.
Obviously authentication and access control is key. Microsoft should not be able to delete their competitors' listings. HTTP already has the authentication, authorization, and encryption features that UDDI's SOAP RPC protocol lacks. It already works.
UDDI has a save_business method. This is for uploading new businesses. The HTTP equivalent is PUT or POST. A pleasant side effect of using HTTP methods instead of a SOAP method is that you can do a POST from an HTML form. So with very little effort, the web service can also be a web site.
UDDI has a find_business method. This is no different in principle than the search features built into every web site in the world and search engine sites in particular. That would be a form of GET. On the URI line, the service would take a series of search parameters and return an XML document representing the matching businessEntities (either by reference, as URIs, or by value, as XML elements).
With four basic methods (GET, PUT, DELETE, POST) we could do what UDDI does with dozens of methods. REST is to web services what Reduced Instruction Set Computing (RISC) is to CPUs. But don't take the analogy too far: the costs and benefits are different in this context.