Fix meta.query.representation and remove /optimade in base URLs

[CasperWA]

Fixes #199
Closes #197

Concerning meta.query.representation (#199)

For #199 a regex is now used to match the version part of the URL path.
Note, however that the regex only recognizes the form /vMAJOR[.MINOR[.PATCH]]. So if anything other is passed, the meta.query.representation value will return the full URL path.

E.g., for a server with version 0.10.1 running at https://example.org, a request to: https://example.org/vTest/structures will return a 404 and a JSON response (as expected) with an error object under the top-level errors field, as well as the standard meta fields, where meta.query.representation will be the full path, i.e., /vTest/structures?, where it maybe should be simply /structures?. However, I think this is fine?

Otherwise, for the same server (again, running version 0.10.1 at https://example.org) a request to: https://example.org/v1.0/structures will return the same response, essentially, with the exception of the value of meta.query.representation, which will be /structures?.

For me this is fine, what do you think?

Concerning the removal of /optimade from the base URL (#197)

This has been removed throughout the code base, where I could match /optimade and it made sense.

Addtional

The validator GH Action did not support setting path to /, this PR fixes this, which is indeed crucial concerning the removal of /optimade.

[codecov]

Codecov Report

Merging #201 into master will increase coverage by 0.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #201      +/-   ##
==========================================
+ Coverage   86.62%   86.67%   +0.04%     
==========================================
  Files          39       39              
  Lines        1854     1853       -1     
==========================================
  Hits         1606     1606              
+ Misses        248      247       -1     

Flag	Coverage Δ
#unittests	86.67% <75.00%> (+0.04%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 98c9b4b...be49f53. Read the comment docs.

[ml-evs]

No complaints or comments from me! Cheers @CasperWA.

E.g., for a server with version 0.10.1 running at https://example.org, a request to: https://example.org/vTest/structures will return a 404 and a JSON response (as expected) with an error object under the top-level errors field, as well as the standard meta fields, where meta.query.representation will be the full path, i.e., /vTest/structures?, where it maybe should be simply /structures?. However, I think this is fine?

I think this is fine! In future, we could potentially make the error message more informative by alerting the client that it was the version number specifically that was wrong.

[ml-evs]

One other comment, actually: previously the unversioned URL i.e. localhost:5000/optimade would redirect to the landing page. Do we want to continue that behaviour, i.e. have localhost:5000 redirect to the landing page?

[ml-evs]

I also note that the landing page router is currently untested, I'm happy to make that a separate PR pending this decision.

[CasperWA]

I also note that the landing page router is currently untested, I'm happy to make that a separate PR pending this decision.

Yup, see also #104

[CasperWA]

One other comment, actually: previously the unversioned URL i.e. localhost:5000/optimade would redirect to the landing page. Do we want to continue that behaviour, i.e. have localhost:5000 redirect to the landing page?

Good question. I think this makes sense, yes.