Add 'validate_unversioned_path' option, which is false by default

[ml-evs]

Closes #52.

Problems with this: no way to validate an implementation that only hosts the versions endpoint at its unversioned URL. This should probably be fixed upstream in the validator, at which point we can change the default value of this new setting to True.

[ml-evs]

Your call @CasperWA whether you want to keep the current behaviour ("fully" validating the optional unversioned endpoint) as the default; I think it makes sense to disable it by default and handle the versions endpoint through my validator PR at Materials-Consortia/optimade-python-tools#665.

[CasperWA]

I think you're right about this. By default only validate the required minimum and then everything else can be added on with boolean options. Yeah.

[rartino]

Maybe it would be nice if the validator could separately report MUST and SHOULD-level violations? (And, formally, anything with 0 MUST validations "validates").

But serving the API on the unversioned endpoint is just on MAY level, so IMO not serving anything there should pass the validation without remarks. Nevertheless, IF something is served there, it would be useful to validate that it fulfills the specification. (But also note that there are options to HTTP-forward requests to unversioned endpoints - those need to also pass validation - I plan to add them to our implementation shortly...).

[ml-evs]

Maybe it would be nice if the validator could separately report MUST and SHOULD-level violations? (And, formally, anything with 0 MUST validations "validates").

Although it isn't quite so clear from the output, this should (lowercase) be what the validator is doing already, with the caveat that SHOULD-level violations get lumped in with the "optional" (again lowercase) tests. Of course, there might still be leftover bits that validate too harshly, but in terms of accommodating SHOULD when validating data and models there shouldn't be any problems.

But serving the API on the unversioned endpoint is just on MAY level, so IMO not serving anything there should pass the validation without remarks. Nevertheless, IF something is served there, it would be useful to validate that it fulfills the specification.

👍 The issue here is that unversioned endpoints have a slightly different specification (i.e. necessity of /versions etc) so they do need to be validated either way, I think we are consistent in our solution for this though.

(But also note that there are options to HTTP-forward requests to unversioned endpoints - those need to also pass validation - I plan to add them to our implementation shortly...).

I'm pretty sure the requests library follows some number of redirects by default, so this shouldn't cause a problem. Please let me know if it does...

[ml-evs]

FYI, I have written the README expecting there to be a v2.3.0 release immediately after this PR.

[CasperWA]

FYI, I have written the README expecting there to be a v2.3.0 release immediately after this PR.

No need. This will be updated by the publishing workflow (via the invoke task).

[CasperWA]

If you want to keep the premature version change, no worries. The invoke task shouldn't care. However, it (might) assume that it can always git commit ...

Edit: Ah, you just reverted it. Never mind :)

[CasperWA]

Cheers @ml-evs ! 🎉