by What its web API can do today:
- REST retrieval of bibliographic records as MARCXML, MODS, atom entry, rss item, oai_dc, srw_dc and rdf_dc, as well as OPAC redirection
- unAPI retrieval in formats above
- OpenSearch 1.0 and 1.1, and OSD generation (yes, generation — replace the dash in those URLs with title, author, subject or series to get OSDs for searches other than “keyword”); response formats are RSS 2.0, atom, MARCXML (for the completely insane), MODS and, coming soon, HTML using atom->xhtml client side XSLT, though replacing the format with a “-“, as the OSD does, returns results in RSS for version 1.0 and atom for version 1.1. There is support for limiting searches to specific libraries or local library systems within PINES, though I haven’t yet decided on the best way to expose that functionality in the OSDs — probably an extension namespace would be best.
- Patron book bag publishing in formats above, as well as an OPAC redirect (coming soon: standalone HTML via the same atom->xhtml XSLT as the OpenSearch feeds, in addition to OPAC redirect)
- oISBN
All these web services are based on the relatively simple and thin OpenSRF application, open-ils.supercat, which is a wrapper to simplify part of the open-ils.storage API, and a couple calls to the open-ils.search open-ils.actor applications. All the code was built in the little time I could steal between preparing for 10 full day meetings over the past 5 weeks, and whatever time my loving, and very forgiving, wife has allowed me on the weekends when I should have been doing yard work.
Next up
- RESTful holdings retrieval
- RESTful create and update interface for bib records
- RESTful notes interface (CRUD) for bib records and holdings
- Atom Publishing Protocol create and update interface for bib records
- More output formats for metarecords
- RESTful update/remapping interface for metarecords
- Once the unAPI paste spec starts to appear, an unAPI paste interface
… and lots more, I’m sure.
wow, that’s quite an update
I wrote a whole long comment and when I got the ‘security code’ wrong it lost it. sigh…
Wow. I will definitely point people here when they ask for an example of how to implement OpenSearch well. Very impressive work.
Cheers,
-DeWitt
Michael, that shouldn’t happen again (re: losing your comments like that). Too many anti-spam plugins in play there. Sorry about that.
— Jason
Wow!
The name “supercat” invokes a great mascot image: A superhero cat, replete with cape and mask, and an iconic logo of itself on the cape… napping. It’s a cat, right? I mean, it’s SuperCat, so it can Do Anything and Will, but, it’s a cat, so, it’s napping anyway.
Wow, all of that’s very cool! Very impressive!
One thing, perhaps the namespace for your MODS export is wrong? I believe it should be http://www.loc.gov/mods/v3 instead of just http://www.loc.gov/mods/ or am I off?
Thanks for making this available!
Robby,
Good eye! 😉
We are currently using an older stylesheet for our mods transforms. I plan to update it at some point, but that will require code changes in areas that will soon be depricated, so I’m holding off until we can completely kill the code that depends on the older XSLT.
OK, got it. I just went to look at some web services tools I use and stuck in the SuperCat URL, and they were coming back with no results, and I finally figured out it was a namespace thing.
This is some awesome stuff…
Robby,
We now have proper MODS v3 support. Just use the ‘mods3’ format specifier instead of ‘mods’ (both now exist) and you should get what you want!
Great. I’ve been integrating some search options in a book collection app I wrote for linux called Tellico, and the MODS3 support makes it very easy.