 |
 |
Andrew Hankinson schrieb: > I think that it's supposed to be the exact opposite. APIs, and > especially web APIs, exist to provide access to your data outside of a > specific vendor implementation. If they are open, well documented, free of non disclosure agreements, free to be used/implemented in any kind of software and scenario (I don't claim they need to be free of fees if they provide a valuable service!)... I heard, there are APIs that don't work that way... Those may lock you in, yes. > That way you can have your OPAC from > $BIG_VENDOR, but use the bibliographic data from it in > $OPEN_SOURCE_PROJECT without having to access the database directly > (causing your DBAs to have sleepless nights.) Theoretically anything > that comes over HTTP is some form of structured text, so there shouldn't > be unreadable binary blobs. Oh no, please. We are doing some things that way: Screenscraping HTML. Sleepless nights... That's as good as a publisher sending some hundred thousand metadata records in a somehow "structured" Word document (no joke, Word even refused to open that file, OpenOffice did, very nice: Journal Titles etc. in the headline, article data on the page, must have been a real punishment for the one compiling that beast). > In theory, that's how it's supposed to work. There's still crappy > implementations, but that's not the fault of the API I think you mix up APIs with open standards or documentation... APIs are everywhere in software (they are a fundamental concept of software design), but most are not "open" or intended for "public use" (even Microsoft has a long tradition of APIs, but it took them a long time to embrace the power of open APIs in their products). Regards, Till -- http://twitter.com/tillk