Planning support of non-JSON endpoint?

[public-transport]

Planning support of non-JSON endpoint?

[derhuerst]

Do you think this would be a good way to go if the iOS app already uses the mgate.exe endpoint? Are there more network providers out there still sticking to the old XML markup so that it could serve for others as well?

My gut feeling says that there aren't a lot of apps using stboard.exe endpoints, but this is subjective. On the other hand, I've seen quite a lot of apps that use mgate.exe endpoints only. You might want to check this list and this list to estimate wether writing a client is worth it. Maybe @juliuste knows.

That aside, we're always happy to have more API clients for more systems, in more languages! Public transportation needs to stop being the patchwork mess it currently is.

[derhuerst]

Will close this. If you happen to write or use a client for the XML-based APIs, let us know.

[derhuerst]

I wanted to add support for the saarfahrplan.de-API which also uses HAFAS, but it turns out the app isn't using the mgate.exe endpoint, but the (older?) query.exe one which does not return pretty JSON data, but gzipped hexadecimal files. I've recorded some requests, you can find them here.

Yeah, we've had a look at this endpoint as well.

The iOS app seems to query mate.exe, but it returns an encrypted response. We'd be happy about any hint that helps us reverse-engineer this.

The Android app seems to query stboard.exe with the old XML markup.. The XML markup is different from the JSON markup. I think a separate, but API-compatible lib would be best.

Are there any plans to support other endpoints within this project? I would like to contribute on the integration!

Are you talking about mgate.exe-based endpoints? If so, then yes, we happy to get contributions like #58 and #22. We're almost done with hafas-client@3, but currently the code still lives in the next branch. Have a look at the "Writing a profile" guide!

[ialokim]

The Android app seems to query stboard.exe with the old XML markup.

That's right for departures, but in the case of a journey I couldn't get any understandable XML response...

Does that related to mgate.exe-based endpoints?

My question was referring to endpoints not using mgate.exe.

I think a separate, but API-compatible lib would be best.

Do you think this would be a good way to go if the iOS app already uses the mgate.exe endpoint? Are there more network providers out there still sticking to the old XML markup so that it could serve for others as well?