rideconnection/clearinghouse — pull request #1 by mtjhax (2013-03-20 00:16:37+00:00)
Title: 1041 api crud for trips

resolves [Task #1041](https://panopticdev-apps.sourcerepo.com/redmine/panopticdev/issues/1041)

Notes:
* Ticket cancellation code is in place, commented out pending model support for that feature.
* Came up with a system to use CanCan in APIs. Defined current_user and current_ability as helpers and then using current_ability.can?() and accessible_by(current_ability) in the API code.
* current_user creates an unsaved User for current_provider, with an unsaved Role with name 'api', so no permanent API user or role needs to exist.
* As mentioned, API code is not very DRY, we will want to add improvements as we continue fleshing out the API.
* API Design doc suggested separate API endpoints for originator tickets and claimant tickets, but I chose to mirror the logic in the controller by creating a single endpoint and relying on CanCan abilities to provide proper filtering.
* API index includes every field -- possible we will want to limit to a subset for index, full details in show.
* API does not currently expose any associated objects (e.g. pick_up_location_id is shown, but not the complete pick_up_location). We can add as needed and limit to show action if desired.
* I followed the controller's convention of allowing callers of the create action to pass in an origin_provider_id, relying on CanCan to determine if that is appropriate.
* As a bit of an experiment, I moved the trip ticket filtering logic from the controller to a reusable module and included that code in the API. This could make the API more flexible and result in smaller, more efficient queries.
* Instead of defining new abilities for the API, since they are nearly identical to the Scheduler role I piggybacked it and added the exceptions after (there is only one exception per the matrix).