Web APIs: Flickr vs. GMaps

I was doing a little research on web APIs. Two of the better ones (or at least well known and used) out there are Flickr and Google's Map (GMap.) They present two very different ways to enable third party developers to leverage powerful web services. So I thought I'd do a little compare and contrast.

Flickr's API is a classic procedural library. There are calls for almost any action you could possibly do with all things Flickr : photos, account, tags, sets, etc. You can upload photos, access photo streams, search by tags ... pretty much anything you can do on Flickr's site. Each call is a different HTTP request. You can send the package of your request in a variety of formats: REST, XML-RPC, and SOAP. The REST and SOAP follow the usual patterns for these formats. The REST requests are "pure" HTTP requests. Flickr's XML-RPC is very true to the RPC mode. It uses simple XML to specify a procedure to call along with it's parameters.

You can also specify the format of the response you get back from Flickr. Since they support REST, XML-RPC, and SOAP for requests, it's not surprising they support all these for responses. They recently added JSON and PHP as response formats. I was pleased to see JSON. I can imagine that if I was going to use Flickr's API, I would probably choose to use REST+JSON. Make a pure HTTP request and get back a JavaScript object. Seems like the lean-mean approach to me. I was surprised to see PHP as a response type. In this case, they are referring to serialized PHP objects. The structure of these objects is identical to the JSON structures.

GMaps is different in many ways to Flickr. Instead of supporting procedural calls to Google, everything is object oriented JavaScript. You include a library from Google and then use their objects. Many of their objects provide methods for making calls similar to what you see in Flickr. For example, you can geo-code a location, calculate directions, etc. But you don't make the HTTP request and you don't parse a response. Google's JavaScript objects do these for you.

The differences in these web APIs reflect the differences in these web services. Flickr is more of a pure data service. You can modify data (photos) and query that data (search for photos, etc.) Flickr wants to be your photo database. As such, they give you a number of ways to access your data. What you do with the data is up to you. Show your pics on a website, provide tools for uploading, print the pics, make aprons, whatever...

GMaps wants to draw maps for you. They don't want to give you mapping data for you to do whatever for it. They want to draw. They'll take your data and draw maps with it. They always draw the map, so they give your users a familiar interface that also integrates into Google. All roads lead back to Google.

Thus the APIs to these services are very appropriate for the services. I don't know for sure, but I'd wager they also reflect the programming design behind the services. It seems pretty obvious that Flickr is written in PHP and that Google Maps is written in Java (maybe the last one is less obvious, but I do have a little inside information on that one.) So it's not really surprising that a PHP site would have a very flexible, procedural API, and that a Java site would have more closed, object-oriented API.