Roedy Green wrote:
If we had a common API to get info about a book from a store, this
programming task would be trivial and would not require constant
maintenance. Further, it would not fail in production. No bookstore
gives any warning that is changing the format of its pages, or is
adding or changing wordings.
Further, you would not need to deal with many languages in your code.
It would not be that hard to come up with a format of the file and an
API to fetch it, and even write a sample client and server app. The
hard part is political, selling it. Perhaps Google might ask its
customers to implement it, or the ISBN people.
Perhaps somebody has already done that. It would just take inquiries
to bookstore asking them the URL to access the XXX API.
You have described the problem well. I am no expert in this domain, but
two existing APIs that stand out in this discussion are the Google Books
API (http://code.google.com/apis/books/docs/v1/getting_started.html) and
the Amazon Product Advertising API
(https://affiliate-program.amazon.com/gp/advertising/api/detail/main.html).
For example, in the Amazon API the ItemSearch and SimilarityLookup web
service operations are just your ticket. Google Books API has 'list' and
'get' as REST actions.
Neither of these actually help our problem; they are just examples of
what we would like to have. You're right that the problem is primarily
political; it's getting myriad bookstores to adopt a Simple Bookstore API.
It's not completely trivial technologically, though: your WSDL will be
uniform, but you'd need to write and provide implementations for PHP and
Java and all your other target languages. And _those_ implementations
would probably need to be written as SPIs, so that appropriate code in
each bookstore's backend logic (for their existing website) can be
identified and plugged in (likely with adapters).