gtracy/madison-transit-api — pull request #13 by chris-skud (2014-05-19 03:56:38+00:00)
Title: parking v2 api - include uw lots.

This pull request contains the v2 version of the parking api.

The functional changes can be summarized as follows:
- Added uw lots
- Change in api signature to be more resource based
- Special events logic has changed significantly and no longer tries to filter down to a currently running event. With the addition of the UW lots, detecting if an event is currently active is difficult (maybe impossible) as uw don't provide event-parking start and end times (only event start time). We'd have to guess about the event duration. The most reasonable way I could figure to handle this was to return the collection of all known events for a given lot and leave it up to the client to do filtering. Later, i think we could add a param to at least provide ability to filter down to events starting within a given timespan.
- The lots route has an "expand=" parameter to enable embedding of of special events in the lot record. By default, the service will not return special events so the caller must use "expand=specialevents" if they want them.

Some other tidbits:
- tried to adhere to PEP 8 formatting/style. I am not really a Pythonista so there could be some deviation...
- ParkingData.lots data -- I chose to store (via an in-memory object) as much "static" info as possible about the lots. I figured I could minimize impacts to source html template changes and/or derivations in data hand-coded by folks at the city and UW. It also provided the opportunity to clean up some formatting. So only the "openSpots" field and specialEvents are dynamic. See /parking/parkingdata.py for details.

Potential TODOs:
- implement filter on "operatedBy" field to filter results to only city or uw lots.
- implement filter to only return special events whose start times fall within a certain window.
- Add test cases to test use of memcache (caching special events data)

Code structure:
/parking
- parking.py - main parking handler including header and payload response processing.
- cityparking.py - fetch, parse and merge of city lot availability and special events data
- campusparking.py - fetch, parse and merge of campus availability and special events data.
- parkingdata.py - an in-code representation of the parking lot collection. Essentially the data model with as many fields pre-populated as possible.

/tests
- runtests.py -- test bootstrapper type thingy. Can run it from the command line like so: python runtests.py '/Users/chriss/libs/go_appengine/' '/Users/chriss/code/me/madison-transit-api/api/v2/tests/'
- test_unit_parking.py - unit level tests. these are fast and attempt to test at the method level.
- test_integ_parking.py - uses the actual endpoint handler to simulate a real request. these are slow but useful because they exercise the service end-to-end.

Fun!