The Good

There can never be too many ways to access this kind of government data, the more that are out there, the more they will be used, and ultimately that is one of our primary goals here at Sunlight Labs. There are a few really nice design decisions that are worth noting.

• The API includes methods not only for details on Members of Congress but is more focused on their roll call votes over time.
• The data goes back as far as any readily available sources go, this is a nice touch that makes it easier on people looking to do historical analysis of the behavior of Congress. (Data goes back to at least 1992 but as early as 1947 for Senate biographical data)
• The RESTful API is easy to use and experiment with from a browser. The four methods are easy to understand and don’t require jumping through hoops. They also use standard HTTP error codes.
• They have chosen to use Bioguide IDs as their primary keys, which means that they haven’t introduced yet another identifier for members of congress. [*]
• The data returned is reasonably minimal throughout most of the API, you get back pretty much what you ask for without a ton of irrelevant information to sort through.

The Bad

As nice as the new API is from a technical perspective, there are a few problems that a would-be user might have. These problems primarily stem from the Terms of Use

• 5000 requests per day limit seems a bit restrictive. (it is prominently noted that this is subject to change, but no indication whether this change would likely be in the upwards or downwards direction)
• Section 1.e.vi of the ToS states that you may not use the API for any service that competes with products or services offered by NYT. This comes across as overly broad as one can imagine that a lot of this vote information would be useful for organizations that can in some way be considered ‘in competition with the NY Times.’ (such as local news organizations).
• Section v of the attribution restrictions prohibits archiving of data for access by users "at any future date after you have finished using the service" which would prohibit something like building an application that used the NY Times as an initial source for votes but had no need to hit the Congress API regularly.

The Ugly

Ok, not much is really ugly about this API, as I said it is quite simple and elegant. At the time of this post however output is XML only and let’s face it, XML is ugly. (I have hopes that this will change as the Campaign Finance API is JSON, XML, or Serialized PHP with JSON by default.)

The New York Times should be applauded for their effort in creating both this and the Campaign Finance API, hopefully the future holds more of this from them and we look forward to seeing what they release next. I hope that some of the more troublesome provisions can be revised or clarified as to make it beneficial to a wider audience.