023-Group all structural metadata queries under a structure resource

[sosna]

It is proposed to group all structural metadata queries under a structure resource to ease the understanding of the API. After this has been done, the API would offer only 4 main resources:

• data: to retrieve statistical data
• metadata: to retrieve reference metadata
• schema: to retrieve schemas that can be used to validate data
• structure: to retrieve structural metadata

The new structure query would be as follow: resource/type/agency/id/version (and of course resource/type/agency/id/version/item, for item scheme queries), where:

• resource would take a fixed value (i.e. structure)
• type would be the artefact type, as defined by the SDMX IM (i.e. codelist, datastructure, dataflow, etc.)
• The rest (agency/id/version) would not change compared to the current version
• Each of the path parameters (i.e. all except resource in the definition above) accept the all keyword (in addition, version also accept latest)

So, for example, to get the latest version of the SDMX CL_FREQ codelist, one would do: https://entry-point/structure/codelist/SDMX/CL_FREQ/latest (latest could be omitted as it is the default value if not supplied)

To get the latest version of all structures maintained by SDMX, use the following: https://entry-point/structure/all/SDMX/all/latest or simply https://entry-point/structure/all/SDMX, as all and latest are the default values for the id and version path parameters respectively.

[egreising]

Why not changing the "id triplet" "agency/id/version" to match the way of specifying it in the data and metadata queries as "/agency,id,version/", i.e. separated by commas in a single segment between two slashes? Or maybe it is preferable to change the data and metadata queries to have the "flowRef" components specified as three segments, separated by slashes instead of commas. Bottom line, we should unify the way of identifying the resource in the two query "flavours".