Strange Routing Metadata Api to Tableview Behaviour

[RudiThoeni]

Hi @gappc
I was experimenting by implementing locally on the tourism api a new Endpoint for Events with a new Route v2/Events using my local instance https://localhost:5001 instead of the for tourism known domains https://api.tourism.testingmachine.eu, https://tourism.api.opendatahub.com.

So i created a MetaData Record with name EventV2 with this properties (i list only the relevant here)

{
"Dataspace": "tourism",
"PathParam": [
    "v2",
    "Event"
  ],
  "Shortname": "Event V2",
  "ApiUrl": "https://localhost:5001/v2/Event",
  "BaseUrl": "https://localhost:5001",
} 

Then by using the "Access to tableview" strangely it points to the mobility endpoint

and then the table view tries to get the tableview from the mobility api.....

It seems like since the url https://localhost:5001 is not recognized as a valid tourism url the mobility api is used....
and the configuration of the Metadata Api is not taken .......

you can see this behaviour also on the Test instance https://databrowser.opendatahub.testingmachine.eu/dataset-overview and Filter by EventV2

Can you help me out here, what am i missing/doing wrong?
thx and cheers

[RudiThoeni]

Ok i think this is the reason, you already commented it :)

OverviewLinkTable.vue

// TODO: this is a very dirty hack to determine if the domain is the tourism or mobility // domain. A better solution would be to have a domain property in the dataset metadata, // because that way we can support other domains without code changes. const domain = dataset.value.baseUrl.includes('tourism') ? 'tourism' : 'mobility';

[gappc]

Hey @RudiThoeni, I just took a look, but good to see that you found it out by yourself 👍

Yes, the comment highlights a difficulty in establishing where the dataset originates from (tourism API / mobility API / ...) in order to:

• build correct URLs / Links
• know how to do pagination
• know how to fetch dataset detail information
• know which field to look at to get the ID of a dataset
• ...

At the moment I use the field BaseUrl to extract that information.

I saw that the MetaData dataset has a field called Dataspace, but that seems to be an indication where the dataset belongs to from a semantical point of view. What I need instead is an indication where the dataset belongs from a technical perspective.

Example:

The dataset Weather South Tyrol belongs to the Dataspace weather, but technically it is provided by the tourism API (see MetaData detail)

It would be very helpful having a dedicated field e.g. ApiDomain or ApiOrigin or something like that - or is this information already somewhere available?

Thx :)

[RudiThoeni]

Hey @gappc
thx for the fast answer, you are right we can add a Field that describes what "domain" the api is in a technical sense.
In future the plans are maybe to have also another domain gastronomy which works the same way as the tourism api (maybe it is simply another deployment with different url / database).
So this changes make absolutely sense, as field name i would choose ApiDomain and possible values at the moment would be content and timeseries (@sseppi i think you agree here). Here we don't use tourism/mobility as naming because we defined a more generic naming for the different apis..... So in future the domain gastronomy would have ApiDomain: content and Dataspace: gastronomy set.......

If you agree i can add this field and fill all infos, then we can change on databrowser side?

[gappc]

@RudiThoeni thank you for the clarification. I agree with your proposal, the possible values and the steps to take 👍

[sseppi]

Hi @RudiThoeni and @gappc ,

I post my comments below.

Hey @gappc thx for the fast answer, you are right we can add a Field that describes what "domain" the api is in a technical sense. In future the plans are maybe to have also another domain gastronomy which works the same way as the tourism api (maybe it is simply another deployment with different url / database).

I would prefer not to add too many technical domains, since every domain we add makes more difficult for the data consumer to understand on which API has to query for the data he is looking for. Instead having a food.api.opendatahub.com I would prefer to use a content.api.opendatahub.com/food that queries the data to a replica of your actual tourism. But we will discuss this topic on a dedicated issue together with Luca.

So this changes make absolutely sense, as field name i would choose ApiDomain and possible values at the moment would be content and timeseries (@sseppi i think you agree here). Here we don't use tourism/mobility as naming because we defined a more generic naming for the different apis..... So in future the domain gastronomy would have ApiDomain: content and Dataspace: gastronomy set.......

I agree! This is perfectly in line with my comments above.

If you agree i can add this field and fill all infos, then we can change on databrowser side?

Fine for me.

[gappc]

@RudiThoeni @sseppi while reading your comments it came to my mind that maybe the term domain (as in ApiDomain) is already overloaded.

What do you say if we called the new field something like ApiType (see below for other proposals)? Then we would have e.g. domain gastronomy with ApiType=content and Dataspace=gastronomy

Possible ApiType values would be content and timeseries to start with.

Other proposals (produced by chatgpt) are:

1. ApiCategory
2. ApiVariant
3. ApiMode
4. ApiStructure
5. ApiPattern
6. ApiFormat
7. ApiType
8. ApiStyle
9. ApiClass
10. ApiConfiguration
11. ApiBehavior
12. ApiNature
13. ApiModel
14. ApiSpec

What's your opinion?

[RudiThoeni]

For me ApiDomain,ApiType,ApiConfiguration are all fine @sseppi take the final decision ;)

[sseppi]

For me ApiDomain,ApiType,ApiConfiguration are all fine @sseppi take the final decision ;)

@RudiThoeni @gappc fine for me too!

[RudiThoeni]

ok then let's use ApiType

[gappc]

@RudiThoeni I saw that you've merged the according PR, should we close this issue?

[RudiThoeni]

the only thing i was not sure is if we should do a complete renaming of the domain names (tourism --> content, mobility --> timeseries) inside the code so that ApiType can be mapped directly.....

for now i added a simple mapping if ApiType == content -->domain = tourism if ApiType == timerseries-->domain = mobility,
what would you suggest?

[gappc]

@RudiThoeni You're right, we should clean this up further. Some questions may arise during this process.

To me, one of the questions is how to manage the information of the technical API we are talking to. Example: at the moment, the URL for the different views contains the "technical" API information: BASE_URL/dataset/table/tourism/v1/Accommodation. That way we can make the views and data linkable, together with information about pagination state and filter settings: the URL describes what should be shown and where the data should be read from. I'd keep that concept, because it turned out to be very helpful. What is your opinion, should we keep that "technical" API information as part of the URL?

Given that other questions may arise, should we create a dedicated issue (something like "Code adjustments for API type abstraction") and close this one?

[RudiThoeni]

Hi @gappc ok i will open another issue where we can discuss this further.
I like also this concept and this route BASE_URL/dataset/table/tourism/v1/Accommodation in my eyes should remain as it is...... but let us discuss it into this issue #618

[gappc]

@RudiThoeni thx 👍