This is the first real integration with the Pro Publica Congress API. It's not complete, but I wanted to get a couple endpoints done. I intend to ship this out to users so that we can start getting real world feedback from both users and from Pro Publica.
We now have two screens use the Pro Publica API:
The legislator "home screen", which shows the legislator's main information and photo. The other two "tabs" on that screen, for the legislator's votes and bills, are untouched and use the Congress API.
Showing legislators "by state". This listing comes up when you go to Legislators, and then pick the State tab, and then pick one of the 56 states/districts.
Pro Publica has kindly extended the API rate limit for my key up to 10K requests per day. Neither of the above two screens are tied to push notifications, so they shouldn't get polled automatically by the app. Every API request will be initiated by an individual user.
Some notes:
To assemble a list of all senators and representatives by state, we now make 2 API requests instead of one, as the State/District endpoint is scoped per-chamber.
We now consistently reload the legislator's information from the API every time we visit their home screen. Previously, we were able to reuse information from the listing endpoint and feed it directly into the home screen, so that a new API request wasn't necessary to re-download that information for a specific member. However, the dearth of fields on the State/District endpoint makes that challenging for this application.
The State/District endpoint uses a name field without individual names, but we want to sort by last name and use our typical name display algorithm. So I'm doing some crude string splitting on names, which could result in inconsistent name display, in some edge cases, on the listing than on the home screen for a meber.
I filed a bunch of issues on the PP API issue tracker that track small bugs and some refactoring suggestions I made after implementing as a client. Some of these were small things, like using null or boolean values instead of strings, and some were larger, like suggesting potentially breaking field renames or data hierarchy changes.
This is the first real integration with the Pro Publica Congress API. It's not complete, but I wanted to get a couple endpoints done. I intend to ship this out to users so that we can start getting real world feedback from both users and from Pro Publica.
We now have two screens use the Pro Publica API:
The legislator "home screen", which shows the legislator's main information and photo. The other two "tabs" on that screen, for the legislator's votes and bills, are untouched and use the Congress API.
Showing legislators "by state". This listing comes up when you go to
Legislators, and then pick theStatetab, and then pick one of the 56 states/districts.Pro Publica has kindly extended the API rate limit for my key up to 10K requests per day. Neither of the above two screens are tied to push notifications, so they shouldn't get polled automatically by the app. Every API request will be initiated by an individual user.
Some notes:
namefield without individual names, but we want to sort by last name and use our typical name display algorithm. So I'm doing some crude string splitting on names, which could result in inconsistent name display, in some edge cases, on the listing than on the home screen for a meber.nullor boolean values instead of strings, and some were larger, like suggesting potentially breaking field renames or data hierarchy changes.