Advice for REST advocates
Thu, 23 Aug 2001 13:09:07 -0700
> Your pitch would be a lot more palatable if there were some
> popular web apps that implemented REST-oriented wires. Then we can do
> a real A-B comparison.
> Unlike the old days, when apps were all locked boxes and we had
> to wait for the developers to get motivated, today enough of them are
> open source so that there's no good excuse for not providing a deployed
> proof of concept.
Well, you could compare xmlStorageSystem
<http://www.soapware.org/xmlStorageSystem> with WebDAV
<http://www.webdav.org/>, which also uses the REST architectural style,
since DAV is based upon HTTP.
Last time I checked, there were 22+ WebDAV servers, 18+ WebDAV clients, and
12 client libraries in a wide range of languages. The latest SecuritySpace
Apache Module Report states that mod_dav is running on 26,584 sites
Steve Jobs states that as of Mac OS X 10.1, iDisk will use WebDAV
<http://www.apple.com/macosx/newversion/>. By some definitions, this
qualifies DAV as being "popular".
As for a comparison, well, there's relatively few entry points in the
xmlStorageSystem specification, so let's take a look:
struct xmlStorageSystem.registerUser (email, name, password, clientPort,
Creates a new account on the server, or updates an existing account.
DAV Analog: none. User registration is assumed to take place out-of-band,
using server-specific mechanisms.
Comments: The xmlStorageSystem model is hardwired to use an email address as
the user identifier. This significantly limits the number of back-ends that
could be used with xmlStorageSystem, assuming you wanted a 1:1 mapping of
xmlStorageSystem user to repository user. It essentially means the
xmlStorageSystem protocol layer must manage its own user base, and existing
sever facilities for managing users cannot be used. Since this is an RPC
style call, and the specification recommends that implementations call this
routine the first time they interact with the system, it is unclear how one
would create a migration path towards a more flexible user model.
There are obvious security implications with sending the (user id, user
name, password) triple across the wire in the clear. While this protocol can
be used with SSL, the specification does not recommend this practice (it is
silent on the issue of security).
struct xmlStorageSystem.saveMultipleFiles (email, password,
Stores one or more files on the remote server.
DAV Analog: PUT
Comments: Since there is no containment model in xmlStorageSystem, it is
unclear whether this command creates an intermediate collection, if
necessary. fileTextList essentially muist contain XML, which is stored
verbatim. That is, the command transfers explicit state across the wire. In
contrast, PUT can handle any content type, including binary types, and is
defined to send a *representation* of the state across the wire (that is,
the server is free to store the state however it wishes). DAV is limited to
writing just a file at a time, and has somewhat higher per-message overhead
than xmlStorageSystem. This could be an issue when dealing with large
numbers of small files. Since DAV is based on HTTP/1.1, connections stay
open once an operation is finished, and so it is easy to transmit a second
PUT once the first has finished. Error reporting for multiple file write
errors is undefined in xmlStorageSystem. It is unclear whether semantics of
saveMultipleFiles is best-effort, or atomic (all files written, or none
struct xmlStorageSystem.getServerCapabilities (email, password)
Returns server capabilities, and user usage information.
DAV Analog: OPTIONS
Comments: OPTIONS only returns server capabilites. HTTP/DAV do not have
quota management capabilities, although some DAV servers have added this on
additionally (e.g., the Xythos WebFile Server <http://www.xythos.com/>)
OPTIONS does not typically require authentication, while
getServerCapabilities does, thus requiring a client to interact with the
server before it can discover the server's capabilities. This would also
make changing registerUser difficult.
struct xmlStorageSystem.getMyDirectory (email, password)
Returns a struct that describes the contents of your folder.
DAV Analog: PROPFIND, Depth 1
Comments: The DAV containment model allows a single user to have multiple
collections, and often there is no one "MyDirectory". It is not clear how
subcollections are indicated in the response to getMyDirectory, and it does
not appear possible to retrieve just the contents of a single subcollection.
struct xmlStorageSystem.pleaseNotify (notifyProcedure, port, path, protocol,
Sends an event notification when one of the files in urlList changes.
DAV Analog: none. WebDAV does not provide event notifications.
Comments: The format of messages sent by the server to the client is
unspecified, and appears that it could vary with notification protocol
Capabilities found in WebDAV but not in xmlStorageSystem:
Namespace management: creating collections (MKCOL), moving to a new name
(MOVE), replicating a resource (COPY)
Overwrite prevention: If two users are writing to the same xmlStorageSystem
space (a collaboratively maintained Weblog, for example), it is quite
possible they could overwrite each other's work. WebDAV provides whole
resource locking (LOCK, UNLOCK) on single resources, and collections of
Properties: Arbitrary name-value pairs associated with resources. WebDAV
properties values are well-formed XML, which can be set with PROPPATCH, and
retrieved using PROPFIND.
So, what has this told us about the REST vs RPC debate? Well, the
xmlStorageSystem interface appears to be fairly brittle in places, since it
would be difficult to modifying existing functionality such as registerUser.
xmlStorageSystem is more simple than WebDAV, since it does less, and what is
does do is underspecified in several places. But, this isn't a quality of
its RPC-ness, it's just an accident of this spec. If you look at NSF v4
<http://www.ietf.org/rfc/rfc3010.txt>, you'll find a very precisely
specified RPC protocol.
Curiously, since xmlStorageSystem is being used to author remote Web
resources, HTTP GET is used to read the resources, and hence
xmlStorageSystem gains the benefits of the REST approach where it counts
most, on the read side. One benefit is that xmlStorageSystem is able to make
use of caching proxies.
In terms of adoption, the REST vs RPC effects seem to be swamped by the fact
that both are human-readable protocols, and both leverage the HTTP stack,
albeit in different ways.