Presence of Point[] parameter in /coverages/{coverageId}/data

[caspervdw]

In the description of the data endpoint there is the Point[] query parameter:

Lever tijdseries op een of meer X,Y-punt(en) in het grid. (Meerdere punten worden opgegeven door een puntkomma-gescheiden string: 1203.6,142.0;1424.3,171.2;...) Response: een json file met een lijst van tijdseries, conform de response van het /timeseries end point van de @@@TODO: DD-API. De lijst is één lang als er om één punt is gevraagd. Als de coverage het resultaat is van een ensemble run, moet ook de realization parameter worden meegegeven.

I like to argue that (if we want this at all) this functionality should go into a different endpoint (like coverages/{coverageId}/point-data)

This is mainly because the response types are different. What does the coverages/{coverageId}/point-data endpoint represent? An 2D raster or a list of 1D timeseries? It is in accordance to the REST principles to separate different objects into different endpoints.

A more concrete reason is that having query-parameter dependent response datatypes doesn't fit into the OAS3 scheme. Another issue is that "realization" is required only if "Point[]" is given.

[GeriWolters]

I believe your reasoning is valid. Having different response types only makes is harder to parse the response, although the provider block gives you a clue as to what type of response you are dealing with. I believe splitting the endpoints would indeed be much cleaner.

[stefhummel]

The same suggestion was made by Deltares reviewers.

[stefhummel]

(During team discussion) Indeed create separate end point, because of the different response. Note: for now this leads to a json response according to the DD-API. In the future other formats might be supported (e.g. netcdf-CF)