Comments (14)
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.
from transport-apis.
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.
from transport-apis.
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
from transport-apis.
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).
from transport-apis.
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.
from transport-apis.
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.
from transport-apis.
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.
from transport-apis.
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.
Additionally this could be something to report back to VDV so they could consider adding it to a updated TRIAS-verison for the future?
from transport-apis.
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.
from transport-apis.
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.
from transport-apis.
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.
Totally agree. What I meant, was that authorization or content-type could be added to be a part of the specification.
from transport-apis.
from transport-apis.
Merge Request #52 was just merged, forgot to mention it in this issue. I created another one #53 for a first json file.
from transport-apis.
#55 added VRN
from transport-apis.
Related Issues (9)
- document on-board passenger information APIs HOT 10
- add KVB HAFAS
- How to document endpoints blocking certain user-agents? HOT 1
- Document Motis APIs HOT 1
- document SNCB/NMBS rest.exe HAFAS API
- Ulm OTP: Homepage not available anymore HOT 3
- otpGraphQL: remove supportedTransitModes field HOT 2
- version field for Trias HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from transport-apis.