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
Given that the REST APIs for tourism and mobility behave different for certain features (e.g. pagination, filter), we need a way to define which API should be called for a certain dataset and which code path to take in the frontend.
For example, we need to know that we should call the tourism API for the Accommodation endpoint and the mobility API for the EChargingStation endpoint and that we have to invoke the according code for pagination, filter, ...
If we open up any of the views in the Data Browser, the information which API to call is retrieved from the URL, e.g.
The problem is, that we need a way to store / get this information when we build links out of the MetaData API.
At the moment, the Dataspace property is used, but using that property is not right, because it's intention is to provide an abstract categorization for the user.
After our last meeting we decided to use the BaseURL information (e.g. https://api.tourism.testingmachine.eu) for datasets defined by the MetaData API. This should work, but there are drawbacks:
we need to map the BaseURL to the according REST API (at least to know what code path to take eg. for pagination). If we do that, we need to ensure that the BaseURL has consistent values
if in the future we want to change the URL to a REST API, we need to change all BaseURL values for all datasets
@sseppi@RudiThoeni@mrabans@MatteoBiasi what do you think, could that be a way to solve the problem? Another option would be to introduce a dedicated field, but we are not sure if that is better. What's your opinion on it?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Given that the REST APIs for tourism and mobility behave different for certain features (e.g. pagination, filter), we need a way to define which API should be called for a certain dataset and which code path to take in the frontend.
For example, we need to know that we should call the tourism API for the Accommodation endpoint and the mobility API for the EChargingStation endpoint and that we have to invoke the according code for pagination, filter, ...
If we open up any of the views in the Data Browser, the information which API to call is retrieved from the URL, e.g.
tourism
path in the URL. From that information we can infer that we need to call thetourism
REST APImobility
path in the URL. From that information we can infer that we need to call themobility
REST API (note that this link does not work yet, a PR is in work)This works quite well.
The problem is, that we need a way to store / get this information when we build links out of the MetaData API.
At the moment, the
Dataspace
property is used, but using that property is not right, because it's intention is to provide an abstract categorization for the user.After our last meeting we decided to use the
BaseURL
information (e.g. https://api.tourism.testingmachine.eu) for datasets defined by the MetaData API. This should work, but there are drawbacks:BaseURL
to the according REST API (at least to know what code path to take eg. for pagination). If we do that, we need to ensure that theBaseURL
has consistent valuesBaseURL
differs between the deployments, e.g. https://api.tourism.testingmachine.eu is used in the TEST environment, while https://tourism.opendatahub.com is used in the PROD deploymentBaseURL
values for all datasets@sseppi @RudiThoeni @mrabans @MatteoBiasi what do you think, could that be a way to solve the problem? Another option would be to introduce a dedicated field, but we are not sure if that is better. What's your opinion on it?
Beta Was this translation helpful? Give feedback.
All reactions