Posts Tagged ‘API’

Discogs’ API Developers

Wednesday, March 25th, 2015

Although the internet is overflowing with deep data most of it is trapped in old APIs that make working with the data complicated. Wikipedia, one of the largest repositories of contributed information in several languages, still relies on an old MediaWiki API that is almost useless at any meaningful search. Sites have sprung up to try to deal with these shortcoming such as DBPedia that tries to wrangle all this information into a standard meaningful API. But how great would it be instead if Wikipedia developers actually created and maintained a powerful API. It would mean giant leaps to the integration and usefulness of Wikipedia. All of the sudden any app would be able to take advantage of all the crowd sourcing done in Wikipedia in a reliable way.

As much as I wish the above for Wikipedia, this blog post is about the developers who have done just that. The Discogs developers have been constantly maintaining their API. Although they had gone down a path I did not approve of recently with adding limits to the number of images that could be downloaded per account as well as requiring OAuth verification, that was complex and cumbersome to implement. They are now fixing those issues while maintaing backwards compatibility. So the good news is that our search plugin for Discogs will continue to work without update. We have already used the Google OAuth framework to implement authentication with our own private account, to make it as easy as possible for users. But new developers wishing to integrate Discogs will have a much easier time using a simple key/secret pair. The 1000 image limit has also been removed and the signed URL provided directly in the downloaded information. This is the kind of simplicity one wishes in all APIs.

I mention Discogs by name only because they are the latest site in adding simple new features to make accessing their data by their users easier. But the truth is many developers have been doing an extraordinary job sharing their data via an API. The TMDB API always comes to the top when I am asked about good API designs, it has been easy to work with and 100% reliable for DVDpedia. The TV Rage and TheTVDB are more complex APIs but work well all the same. In the music world MusicBrainz has been solid. MovieMeter has been moving backwards in features since maintaining the original API required a lot of work for a single developer. BoardGameGeek has an API that is embedded into their system that works but could do with some 2015 technology improvements. But speaking of improvements the API that could really do with some love is the Library of Congress. Although now using a new SRU standard, it’s still based on a system that is decades old. But it seems updating the way libraries share their catalog is a gigantic undertaking. The above list is not extensive as there are many other search sites with APIs that we are thankful exist: OFDB, Open Library, Google Books, Freebase (Bought by Google), Amazon AWS and AbeBooks.

We look forward to a world where standards improve, for example JSON format has been marvelous at making integrating APIs easy and consistent. Some day information on the internet will be truly available to our future computer program overlords that will do all the communicating for us and present the information we want on command. Hopefully they will be able to even update themselves as data improves. In the meantime we hope developers continue the hard work of maintaining all these endpoints and adding more where needed.

Open Letter to Jeff Bezos

Friday, July 24th, 2009

Dear Mr. Bezos,

Recently we had to remove our iPhone and iPod Touch program Pocketpedia from the iTunes App Store because it synced Amazon information from our desktop applications to a mobile device and also allowed the Amazon catalog to be searched from a mobile device. The Amazon Product Advertising API provides reliable access to a wealth of information that benefits my company as a source of data and your company by encouraging more sales. We are unable to find a reason why this API service should explicitly exclude use on mobile devices.

Let me tell you a bit about our applications, in the hopes of changing your mind. The Pedia programs (DVDpedia, Bookpedia, CDpedia and Gamepedia) are used to build personal media catalogs. Users create a list of items they own, those that they have lent out and those they wish to buy in the future. It allows them to get organized and keep track of both past and future purchases. As you can appreciate, having their data on the go is a great reference and convenience.

It’s our belief that Pocketpedia does in no way compete with Amazon Mobile or SnapTell (which you recently acquired). They serve different markets: Pocketpedia is a home reference application while yours are shopping applications. Even if they did compete I don’t see a reason to suppress them as the winner will always be Amazon selling the final product. And iPhone users can only benefit from more options in the App Store. Of course you’re in a better position to decide what’s best for Amazon but from the outside the clauses excluding mobile devices seem like a losing situation for all: Amazon, customers and third-party developers.

Both clauses mention that written approval can be obtained to use the Amazon data on a mobile device, yet I can’t find a single app that has received this approval. In the hopes of positive changes at Amazon I would like to suggest that these clauses be dropped. If this is not possible, I formally request that Bruji as well as our competitor Delicious Monster (who have also run afoul of the mobile clause) be given permission to sync Amazon data to the iPhone and iPod Touch. Moreover, if Amazon is feeling kind, we also request the use of the Product Advertising API directly on the iPhone to search and add new items.

I write this as an open letter because getting a meaningful conversation going with Amazon has been impossible for both my customers and me. Your support system does not allow replies to emails sent directly from your Associates Account Specialist. Messages filled out in the Amazon contact page only get canned responses without explanations. The Amazon customer service has lost its touch in the last few years but more worrying is that Amazon has become increasingly closed, controlling and unfriendly. I know that our users have been writing to Amazon in the past week to register their dismay about the loss of Pocketpedia and I would like to be able to give them positive news thanks to their efforts.

Hoping for change,
Conor Dearden