Repository navigation
Meta Information
home > Operator information > Meta Information
The TOMP-API contains a self-describing endpoint (/operator/meta). This endpoint contains information about the endpoints that are implemented and a series of ‘process identifiers’, describing how the process flow around these endpoints should be. Alternatives like HATEOAS don’t cover the required functionality. These Process Identifiers are described in the wiki on Github (ProcessIdentifiers).
For example, in the planning module, there is the process identifier ‘ASSET_BASED’, telling that the TO provides nearby assets to end-users in the near future. It supports the pick-up-and-go scenario. The MP cannot reserve assets from this TO as long they don’t provide ‘PLANNING_BASED’ as well.
But in combination with ‘ASSET_BASED’, the MP must supply a reference to the asset. When the TO requires the identifier ‘QR_SCAN’, the reference to the asset can be gained by the MP using a QR scan. There are quite a few process identifiers, making it possible to describe the process of the TO. The list of process identifiers on Github is leading, but new identifiers will be introduced in the future, together with new releases of the swagger file.
This is an example response:
[
{
"version": "1.0.0",
"baseUrl": "https://dummy-bikes.org/",
"endpoints": [
{"method": "POST","path": "/planning-options/","status": "IMPLEMENTED"},
{"method": "POST","path": "/bookings/","status": "IMPLEMENTED"},
{"method": "POST","path": "/bookings/{id}/events","status": "IMPLEMENTED"},
{"method": "GET","path": "/bookings/{id}","status": "NOT_IMPLEMENTED"},
{"method": "PUT","path": "/bookings/{id}","status": "NOT_IMPLEMENTED"},
{"method": "GET","path": "/bookings/?state=","status": "NOT_IMPLEMENTED"},
.....
],
"scenarios": [
"POSTPONED_COMMIT"
],
"processIdentifiers": {
"planning": [ "ASSET_BASED", "QR_SCAN" ],
"booking": [ "ACCESS_CODE_DEEPLINK", "ACCESS_CODE_IN_COMMIT_EVENT"],
.....
]
}
}
]
Since version 1.5.0, we included the process steps in the meta endpoint:
"steps": {
"planning": [ { ... } ],
"booking": [ { ... } ],
"onboarding": [ { ... } ],
"offboarding": [ { ... } ],
"pausing": [ { ... } ],
"resuming": [ { ... } ]
}Introduction
- Roadmap
- Semantic versioning
- Use cases
- Changes per version
- Contribution
- Participants
Workflow
- Operator information
- Planning phase
- Booking phase
- Trip execution phase - start
- Trip execution phase - on route
- Trip execution phase - end
- Support
- Payment
Points of attention
- Modalities
- Specifying locations
- GDPR
Eco system
- Relations
Introduction
Scope of the TOMP-API
Versioning and releases
Process Flows
- Authentication
- Operator Information
- Privacy and Registration
- Planning Module
- Booking Module
- Trip Execution Module
- Payment Module
- Support Module
Meta-Information
Reference implementations
To-dos and risks
Technical Specifications
A1 List of terms and definitions
A2 Passenger characteristics dictionary
A3 APIs available on the transportation ecosystem
A4 Overview of the User stories
A5 Authors, Architects, collaborators and stakeholders involved
A6 Adoption and Implementation of the TOMP-API