Inconsistent capitalisation of classes in URLs

[paulmillar]

According to W3's "HTML and URLs" URLs should be case sensitive:

There may be URLs, or parts of URLs, where case doesn't matter, but identifying these may not be easy. Users should always consider that URLs are case-sensitive

However, the API documentation is inconsistent in how the classes are represented within URLs.

For example, on the api-calls page, the Get dataset call is documented as:

GET /datasets/{pid}

However, the example curl invocation (immediately below) is

curl -X GET --header 'Accept: application/json' 'http://localhost:3000/api/Datasets/{pid}?filter={filter}'

Note the difference between datasets and Datasets.

This problem seems to be systemic, with all documentation mixing capitalised- and lower-case versions of the class name.

If Datasets and datasets are meant to be synonyms for the same resource (i.e., the word is case insensitive) then this must be clearly documented, as this would go against the common semantics of URLs.

The API documents appear to have no statement on case sensitivity, so one would assume the URLs are case-sensitive (per W3's document).

Therefore the API document is inconsistent.

[paulmillar]

Oscar Matilla (CELLS/ALBA) reported to me that he was informed by Toni Fernandez (also CELLS/ALBA) that the correct capitalisation is Datasets.

[paulmillar]

To add further confusion: D3.1 "API Definition (common search API)", when defining the API, uses the lower-case classes: datasets, documents, ...

In D3.1, the capitalised classes (e.g, "Datasets") appear only in English prose, never in the technical documentation (API calls, etc).

Therefore, when reading only from D3.1, I would take datasets to be the correct term in a URL; e.g., https://example.org/search/datasets/count is correct.

The use of Datasets in the URL is wrong; e.g., https://example.org/search/Datasets/count is wrong.