You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it is not possible to set custom headers for the HTTP import. It would be cool if the ODS does support setting custom headers, because there are plenty of use cases for HTTP headers:
response format: A datasource might support multiple response formats. The format is often selected based on the Accept request header.
localization via the Accept-Language header
authorization via the Authorization header. Of course, this would then be no real open data. But for example many public transport providers to allow accessing their data (e.g. timetable, station information, delays, ...) with an access token, that is provided after registration.
other custom headers
I am currently adjusting my fault tolerance tests and instead of setting up a custom mock server to perform imports against. I wanted the import to be performed against the adapter itself and query the list of datasources. Unfortunately, the adapter returns XML when not specify the Accept header. This is not a big issue for me, because I can use the XML interpreter to transform it back to JSON. But this has some limitations because the output JSON is slightly different (e.g. numbers and booleans are present as strings, ...). That's why I came up with the idea of adding support for setting custom HTTP headers for the import.
The text was updated successfully, but these errors were encountered:
Probably to be implemented as generic key value pairs?
Yes exactly. Might also be worth to enable support for custom headers not just inside the static datasource configuration, but also as dynamic runtime parameters.
Currently, it is not possible to set custom headers for the HTTP import. It would be cool if the ODS does support setting custom headers, because there are plenty of use cases for HTTP headers:
Accept
request header.Accept-Language
headerAuthorization
header. Of course, this would then be no real open data. But for example many public transport providers to allow accessing their data (e.g. timetable, station information, delays, ...) with an access token, that is provided after registration.I am currently adjusting my fault tolerance tests and instead of setting up a custom mock server to perform imports against. I wanted the import to be performed against the adapter itself and query the list of datasources. Unfortunately, the adapter returns XML when not specify the
Accept
header. This is not a big issue for me, because I can use the XML interpreter to transform it back to JSON. But this has some limitations because the output JSON is slightly different (e.g. numbers and booleans are present as strings, ...). That's why I came up with the idea of adding support for setting custom HTTP headers for the import.The text was updated successfully, but these errors were encountered: