Connects the request to app to approrpriate scenario database
- 200: [
route.json
]
returns
- 200: [[
tripId
]] - 404: No such route exists
The list contains all trips in the route, grouped by their unique path. In order to be unique the path has to follow the same stops with the same timings.
returns
- 200:
trip.json
- 404: No trip exists given
trip_id
androute_id
Returns combined record of trip, stop times, stops and requencies.
returns
- 200: If trip is deleted
- 404: No trip exists given
trip_id
androute_id
This will delete the single trip with specified ID, not the whole path group.
accepts trip.json
returns
- 201: If update is accepted
- 404: If :tripId and :routeId are not matched in
This request will perform the same grouping operation as a GET on /route/:routeId. All trips in the same group as the trip specified by the :tripId will be deleted and the provided trip will be saved to the database in their place.
All trips must be saved with a valid service_id
. However, this API does not have any concept of service_id
and no way to expose this information. Hypothetically if the service client was performing a replacing POST they could send back service_id
unmodified it would preserve the trips presence in the service calendar when a TransitSystem
is later generated. However, there is no such recourse for inserting POST request.
Therefore, at time of scenario creation a new CalendarRecord
with value of 'ALWAYS' will be created with start and end dates of the scenario and enabled on every weekday. All incomming POST requests will be re-written to reference the 'ALWAYS' service.
When updating or inserting a new Trip record the user is able to specify the location of the stop. These can not be interpreted as location updates of already existing stops because it would potentially change the characteristics of trips other than those currently being replaced by the POST request.
Therefore, at time of insertiong or update the stops will be given a new name with a 'magic' prefix (ex: TEMP-{trip_id}-{sequence_id}
). Accordingly on update the service will attempt to delete all such stops associated with the TripRecords being replaced.