This is part 1 in a series of posts about creating a mobile web app for browsing music databases.
In my continuing quest to up my web/mobile game, I decided to build a web app for searching the All Music database. There are a number of music metadata repositories on the web, some robust and some paltry. The one I like the best is run by Rovi and powers All Music, along with iTunes and several other big name media products. They have an iOS app that allows you to access all parts of the data store. It’s a great thing, but the search portion is not very user friendly and doesn’t always work the way you expect.
My goal was to create a basic search form that allows you to look up an artist, album, or song title. The native app had an all-in-one search feature where it tried to dynamically show you results for what it thought you were looking for, but it often failed to return what I wanted. I understand the ease and utility of having a single field for different types of information, but I wanted to run specific searches.
The first step was creating an API that would essentially wrap the calls to Rovi’s RESTful API. I didn’t want to interface directly with Rovi for several reasons: to allow the results to be formatted differently if I wanted, to make it easier to switch to a different data store in the future, and so I wouldn’t have to allow cross-origin requests. I went with the standard Web API project in Visual Studio 2013.
Getting the routing to work properly was the only real hurdle with the API. The default Visual Studio template sets up routes that include /api/<controller>. But I just wanted /api and not the <controller> part. It’s tricky because the base controller class is ApiController. The MVC convention is controller class names are of the form <my_ctl_name>Controller and then my_ctl_name becomes part of your route. Having my own class called ApiController wasn’t possible, so I called it SiteApiController. But how to tell all requests to use that controller? Enter WebApiConfig.
I removed all the default routes and added two new ones: one for searching and one for lookups. I was able to specify the exact controller class and a route template that only included /api and not a controller designation. Bonus points to Microsoft for allowing lots of route configuration options.
Even though I only needed to make single, synchronous requests to Rovi, I used HttpClient to do it. There might be a need in the future to make multiple simultaneous requests to build a query result, if so it will be easy to make them async. The next step was the front end.