Library vendor-provided software, as well as library-data-focused websites, have started to offer API’s. But many of these API’s tend to, well, not be very good. Difficult to use, designed for specific pre-planned use cases instead of flexibly exposing functionality, sometimes not behaving as documented, with poor support (try filing a support ticket with one of our content platform vendors regarding an API issue; count how many hours you have to spend to escalate your ticket to someone who has any idea what you’re talking about).
To be fair, designing a good API is hard (meaning ‘expensive’ in developer/designer time if nothing else), and while being able to say you have an API seems to have become neccesary for marketting your product, it’s unclear how many customers will actually use that API, and whether having an actual good API will get you more business. Of course, there’s a chicken and egg thing here too; the better designed and supported an API is, the more likely it will be used. But, like with many aspects of software development, if you really want a good API, you’ve got to have experienced capable people developing it — with input from potential users, but you can’t expect potential users/customers to design it for you, or expect you’ll wind up with something good if you just do exactly what a couple customers ask for.
Anyhow, here’s a brief blog post with some principles of good API design. Vendors serious about providing a good API would do well to think about these issues.
Interestingly, one of the examples in the article is from the library domain, I am curious what experience the blog author has working in this market — and I can guess what legacy back-end poor architecture leads to the particular issue he hints at, and makes it difficult to provide a good API. From the provider’s point of view, it is definitely difficult to provide a good API on top of poorly architected software.