Have the trip_id be generated by the provider not the agency #63
Comments
|
Yep -- this is also key to avoid duplicates in a number of failure scenarios. |
|
Trip IDs should be generated differently in the Provider and Agency APIs, so they might not be equivalent concepts. UUID4 offers a way to ensure that these are mutually globally unique, but for each API the hosting organization (vendor or city) should be responsible for generating its own internal primary keys. |
toddapetersen
added a commit
that referenced
this issue
Dec 12, 2018
This is a baseline restructure of the Agency api to address a number of endpoint changes and incorporate feedback received in previous issue and PRs (#161, #116 and #63). Major changes: * `provider_id` is passed as part of an authorization bearer token. * Looking up and registering vehicles use standard `GET` and `POST` operations on `/vehicles` endpoint. * The `/vehicles/{vehicle_id}/event` allows Providers to `POST` events to affect vehicle status. The vehicle status is modeled around a state flow that is modeled in Vehicle Events table. * Deregister vehicle, trip start and end are now events. * Events for `trip_enter` and `trip_leave` were added to address trips that do not start or end in the Agency jurisdiction.
hunterowens
pushed a commit
that referenced
this issue
Dec 20, 2018
* Restructure api and add event-status model This is a baseline restructure of the Agency api to address a number of endpoint changes and incorporate feedback received in previous issue and PRs (#161, #116 and #63). Major changes: * `provider_id` is passed as part of an authorization bearer token. * Looking up and registering vehicles use standard `GET` and `POST` operations on `/vehicles` endpoint. * The `/vehicles/{vehicle_id}/event` allows Providers to `POST` events to affect vehicle status. The vehicle status is modeled around a state flow that is modeled in Vehicle Events table. * Deregister vehicle, trip start and end are now events. * Events for `trip_enter` and `trip_leave` were added to address trips that do not start or end in the Agency jurisdiction. * Fix field names for provider api consistency * Linking to provider.csv
|
This seems to have been resolved in #194. @hunterowens I think we can close? |
|
Agreed with @oderby. Resolved in current Agency version. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the current spec,
trip_idis generated by the agency in response to astart_tripcall. I think this creates an undesirable dependency on the agency’s infrastructure.If I’m reading correctly, the
trip_idis also used inend_tripandtripsAPIs. Now, imagine that the agency’s API server goes down for whatever reason (bugs, power outage, network outage, server maintenance, etc.). The provider will attempt to callstart_tripand get a failure. Now they don’t have a trip ID with which to identify the trip, so they are in a pickle. If they go ahead and start the trip, it will never have an agency-approved trip ID. If they don’t start the trip, their service is effectively shut down.I would suggest moving
trip_idto be an argument tostart_triprather than a return value. This would eliminate the dependency.Thanks for all the good work!
The text was updated successfully, but these errors were encountered: