[Backend, request] API requirements

[p1d1d1]

• [x] The API should provide "one unique" get data endpoint
• [ ] The get data endpoint is able to return all available datasets, meaning the query parameter should not be mandatory, thus
• [ ] The API should support pagination
• [x] The API returns for each dataset: [ ] an ID [ ] all data available in the source data (minus the field "UPDATE" which is overall empty) [ ] any additional information you can derive via data post processing (e.g. categories) according to the following schema where the columns names of the source file are overwritten:

{ "id": 1234, "provider": "", "title": "", "name": "", "preview": "", "tree": "", "group": "", "abstract": "", "keywords": "", "legend": "", "contact": "", "endpoint": "", "metadata": "", "service": "", "maxZoom": 5, "centerLat": 1234, "centerLon": 1234, "bbox": "", "category": "" }

• [x] The API get data endpoint should support filtering by provider and/or by service
• [x] The API should provide and additional data/{datasetID} endpoint

[FStriewski]

Pagination For what reason(s) would you require server-side pagination? The search as-is is sufficently fast. Clicking through a lot of pages tends to frustrates users and usually means that a sufficent result has not be achieved by the combination of search terms (or our algorithm). I would suggest to keep it frontend only unless there is a good reason for it - also to save on development time.

getAll This is a very costly operation so I would advise against being able to call that endpoint on a "blank" search without query parameters. For a full database dump we should move that functionality behind specific UI elements.

fields in table Bit of a UI challenge with the available space and the current MUI table. We probably cannot display all fields at once (as seen in earlier experiments) and would need to the decide on the most important ones (for the user to decide which results are relevant). We could maybe add an "expand" feature, so that you get the remaining fields when clicking on a table row. This could, for instance, be the more technical and less human readable properties (like coordinates, zoom level and such). Depends on the use case / user requirements.

[p1d1d1]

@FStriewski

• concerning "getAll and pagination": there is at least the following use case that we have to support: "Give me all WxS offer of provider X". Then when it comes to e.g. Bund, you'll get around 1000 datasets, meaning pagination does still make sense.

• concerning "fields in table": please do not mix API and GUI. The API should be able to return all properties. Third parties could use the API to develop applications and those properties are more or less all important. On the GUI side not all properties need to be shown: see dedicated issue.

[FStriewski]

Yes, you're right, the API will return all values except for "update". I'll move pagination to a its own ticket and will handle it separately. All others features should be easy enough to implement right away, so that they'll be available for the 17th.

I noticed you renamed some of the fields, e.g. "owner" to "provider" and so on. Is that definete? In that case we should adjust the naming in both, the scraper (output) and the schema.

[FStriewski]

Changes, except for pagination, implemented with this MR: https://github.com/FHNW-IVGI/Geoharvester/pull/32