Eric,
On 29/06/07, Eric Lease Morgan <[EMAIL PROTECTED]> 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
