{"id":48,"date":"2006-01-17T17:57:40","date_gmt":"2006-01-17T22:57:40","guid":{"rendered":"http:\/\/dilettantes.code4lib.org\/2006\/01\/17\/on-unapi\/"},"modified":"2006-01-17T17:57:40","modified_gmt":"2006-01-17T22:57:40","slug":"on-unapi","status":"publish","type":"post","link":"https:\/\/rossfsinger.me\/blog\/2006\/01\/on-unapi\/","title":{"rendered":"On unAPI"},"content":{"rendered":"

After arguing with Dan<\/a> for hours on how to implement unAPI<\/a>, I decided to take him up on his request and implement an unAPI service for our OPAC.\u00c2\u00a0 This way I would have some real world experience to back up my bitching.<\/p>\n

So, here you go<\/a>.\u00c2\u00a0 This script takes our SRU to OpenSearch services for the OPAC and the Universal Catalog.\u00c2\u00a0 I’ve modified the OpenSearch CGI to include the unAPI identifier.<\/p>\n

The unAPI service is written in PHP and calls the SRU service and presents the results accordingly.<\/p>\n

So, my reactions:<\/p>\n

    \n
  1. The JSON<\/a> requirement doesn’t really bother me.\u00c2\u00a0 Whatever is chosen is rather arbitrary, so I’m ok with JSON.\u00c2\u00a0 I’d be just as ok with XML or text delimited.\u00c2\u00a0 I see no real difference.<\/li>\n
  2. I am not entirely convinced that just exposing the metadata (with no wrapper) is scaleable.\u00c2\u00a0 I’m not saying I can’t be convinced, I’m just saying I’m not currently.<\/li>\n
  3. I see no point in sending the status along with the response.<\/li>\n
  4. This is, indeed, much simpler than making an OAI-PMH server in PHP over Voyager.<\/li>\n
  5. I would really prefer parameters to paths.\u00c2\u00a0 I think there are too many assumptions about the implementor (and the future) to use paths.<\/li>\n<\/ol>\n

    What I am still not entirely sure about fundamentally, however, is why<\/em> we need another sharing protocol.\u00c2\u00a0 Dan claims it’s because OAI-PMH and ATOM are still too complicated<\/a> for stupid people and the less technically inclined to pick up and he wants something simpler.<\/p>\n

    What I don’t understand is why we don’t just make a “simpler” API to one of those protocols.\u00c2\u00a0 Choose a particular syndication protocol (after all, that’s really what OAI-PMH is) and then just make an API to “Gather\/Create\/Share” with it.<\/p>\n

    Personally, I am much more interested in making our OAI-PMH archives and our SRW\/U servers available via ATOM, much like we made SRU available to OpenSearch.\u00c2\u00a0 That way we pick up on the wide variety of tools already out there.<\/p>\n

    This interests me on other levels, since I’m really starting to picture the Communicat as a sort of ATOM store.<\/p>\n

    I see a lot of potential with unAPI (a whole hell of a lot of potential), but I would rather utilize an existing protocol (especially one that promises to have a lot of users, read: ATOM) than build another library system that is largely ignored outside our community.<\/p>\n

    On a related note, I want to point out what I see as two wastes of library developers’ time:<\/p>\n