 |
 |
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