transport-apis
transport-apis copied to clipboard
public-transport
document OJP/TRIAS APIs
@andaryjo started doing this in the trias-client docs.
@vkrause's kpublictransport also has support for >1 TRIAS endpoint.
Let's define a way to specify all relevant aspects of TRIAS API endpoints in a machine-readable way, so that client libraries can use this information! This way, there will be
- less maintenance, as upstream changes to the individual endpoints will only have to be investigated once.
- better coverage of all existing API endpoints, as client libraries can easily pull the list of all known ones.
Thanks for getting this started! Adding this here has also been somewhere on my todo list :)
We have only tested two endpoints so far, so not a lot of experience on how well things generalize yet:
- SBB (using OJP)
- VVO (using TRIAS)
OJP and TRIAS turned out to be 90+% the same code for us, so we are supporting both with the same implementation, but here we might still want to model them as different protocols I guess.
Besides the endpoint URL, the HTTP Content-Type header for requests seems to be a relevant parameter (or I just haven't found one yet that works universally).
I haven't looked into implementing multi-language support yet, so not sure if the options for that we have for other APIs are relevant.
Besides the endpoint URL, the HTTP Content-Type header for requests seems to be a relevant parameter (or I just haven't found one yet that works universally).
That's my experience as well. application/xml works for most providers, but one I know of explictly requires text/xml. I don't think the TRIAS specification states anything about the Content-Type. So this is something that would need to get included in the protocol-specific options.
Another thought: Most TRIAS APIs require authorization and the implementation is proprietary. Some providers use a RequestorRef XML tag, some use a header and some require you to include an API key / token in the URL path.
This will make it really hard for a TRIAS client to use these specifications as a basis for API connectvity, because it will likely require a custom implementation for every provider anyway.
This will make it really hard for a TRIAS client to use these specifications as a basis for API connectvity, because it will likely require a custom implementation for every provider anyway.
Would it? We could agree to add specific fields/values for each known auth type.
Another thought: Most TRIAS APIs require authorization and the implementation is proprietary. Some providers use a
RequestorRefXML tag, some use a header and some require you to include an API key / token in the URL path.This will make it really hard for a TRIAS client to use these specifications as a basis for API connectvity, because it will likely require a custom implementation for every provider anyway.
Additionally this could be something to report back to VDV so they could consider adding it to a updated TRIAS-verison for the future?
And is there already any current plan on how to continue on this issue? I already started to note down some endpoints, but would rather directly submit them to this repo. I could offer to create a draft in a fork of me, so we have something we can discuss, if no one started on this issue yet.
This will make it really hard for a TRIAS client to use these specifications as a basis for API connectvity, because it will likely require a custom implementation for every provider anyway.
Additionally this could be something to report back to VDV so they could consider adding it to a updated TRIAS-verison for the future?
Adding what specifically?
Personally, I'd like VDV to only use standard HTTP mechanisms, preferably the Authorization header, or at least something that can easily be specified with an OpenAPI spec.
And is there already any current plan on how to continue on this issue? […] I could offer to create a draft in a fork of me, so we have something we can discuss, if no one started on this issue yet.
Yes, create a draft in a fork, then submit a work-in-progress PR against this repo. We can then discuss the markup's details in there.
This will make it really hard for a TRIAS client to use these specifications as a basis for API connectvity, because it will likely require a custom implementation for every provider anyway.
Additionally this could be something to report back to VDV so they could consider adding it to a updated TRIAS-verison for the future?
Adding what specifically?
Personally, I'd like VDV to only use standard HTTP mechanisms, preferably the
Authorizationheader, or at least something that can easily be specified with an OpenAPI spec.
Totally agree. What I meant, was that authorization or content-type could be added to be a part of the specification.
Merge Request #52 was just merged, forgot to mention it in this issue. I created another one #53 for a first json file.
I think it is beneficial to differentiate between the TRIAS implementations. At least the MENTZ implementation of TRIAS is a severely limited subset.
This is the only official documentation I know of, that describes which subset of TRIAS is implemented by MENTZ: https://www.dresden.de/media/pdf/wirtschaft/VVO_Beschreibung_der_Schnittstelle_API_fuer_die_Verbindungsauskunft.pdf
These are discussions about more limitations of the MENTZ implementation of TRIAS: https://github.com/mobidata-bw/TRIAS/discussions
I think it is beneficial to differentiate between the TRIAS implementations. At least the MENTZ implementation of TRIAS is a severely limited subset.
We might want to do this feature-flag-based, not implementation-based, because
- implementations like Mentz's TRIAS API can also have >1 versions, leading to a large number of ever-changing "targets", each support one set of features.
- technically, a TRIAS client should not care about which backend system implements the API, but rather what it supports (and how it does that in some cases).