Eric,

On 29/06/07, Eric Lease Morgan <[log in to unmask]> wrote:
> Here are the only two working examples I have:
>
>    http://dewey.library.nd.edu/mylibrary/ws/?obj=facet&cmd=getAll
>    http://dewey.library.nd.edu/mylibrary/ws/?obj=facet&cmd=getOne&id=2
>

In terms of versioning and user readability (you never know someone
may want to bookmark a url :) ), you could perhaps try a url that
looked something like this using two examples above:

http://dewey.library.nd.edu/mylibrary/ws/v1/facets/
http://dewey.library.nd.edu/mylibrary/ws/v1/facets/2
or even better...
http://dewey.library.nd.edu/mylibrary/ws/v1/facets/formats
which could lead to...
http://dewey.library.nd.edu/mylibrary/ws/v1/facets/formats/microfiche

These urls can be interpreted by Mod Rewrite [1] rules to actually
present the name:value pairs to your perl app.

Of course this approach requires some planning - but in terms of
usability could have a payoff.  If the api were only targeted at
developers and is only ever going to be embedded in code - never to be
seen by the masses -  then name/value pairs may be ok.

In terms of xml output, I would echo Robert "i only have an opinion on
the nature of the xml to return, and only in the case of lists of
stuff: Atom or RSS. i'm really cursing myself for having fallen into
the trap of "hey, with xml i can create my own formats" too often."

Atom or RSS would allow greater mashupability - Yahoo Pipes etc.

Tim

[1] http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html

--
Tim Hodson
www.informationtakesover.co.uk
www.timhodson.co.uk