Wrong response structure at info endpoint @ cod

[fekad]

http://www.crystallography.net/cod/optimade/info

Based on the specification:

• data: The data field SHOULD return only a single resource object. If no resource object is provided, the value of the data field MUST be null.
• available_api_versions: MUST be a list of dictionaries, each containing the fields:
  • url: a string specifying a versioned base URL that MUST adhere to the rules in section Base URL
  • version: a string containing the full version number of the API served at that versioned base URL. The version number string MUST NOT be prefixed by, e.g., "v".

Please note that these issues were discovered during designing the client code and only partially checked against the specification.

[CasperWA]

@merkys do you have a place where issues for your OPTIMADE implementation(s) can be reported?

[merkys]

@fekad thanks for spotting this. I've noticed COD's /info is not understood by the client code, but didn't have time to investigate.

@CasperWA we have a Redmine issue tracker. I have forwarded this issue to COD#669.

[ml-evs]

If it's helpful @merkys, I've posted the output of the validator running on the info endpoint. There may be areas where we are being too strict, so please shout if so!

It looks like there are three minor problems reported:

1. The data field for info/ must contain a single resource object, rather than a list.
2. The meta field must have a provider entry.
3. This looks like a contentious one, we're currently validating meta->implementation->source_url with the AnyHttpUrl model which allows only http/https, I see absolutely no problem relaxing this to allow for different URL schemes (in fact the spec alludes to this already). I'll prepare a fix for this.

$ optimade_validator http://www.crystallography.net/cod/optimade/info -v 4 --as_type info
2020-05-04 12:28:17,785 - optimade.validator.validator |     INFO: Validating response of http://www.crystallography.net/cod/optimade/info with model <class 'optimade.models.responses.InfoResponse'>
✔: http://www.crystallography.net/cod/optimade/info/ - request successful.
2020-05-04 12:28:18,292 - optimade.validator.validator |    DEBUG: Response to deserialize:
{
  "data": [
    {
      "attributes": {
        "api_version": "v0.10.0-dev",
        "available_api_versions": {
          "v0.10.0-dev": "http://www.crystallography.net/cod/optimade/v0.10.0-dev/"
        },
        "available_endpoints": [
          "structures",
          "info"
        ],
        "entry_types_by_format": {
          "json": [
            "structures"
          ]
        },
        "formats": [
          "json"
        ]
      },
      "id": "/",
      "type": "info"
    }
  ],
  "links": {
    "base_url": "http://www.crystallography.net/cod/optimade/v0.10.0-dev/"
  },
  "meta": {
    "api_version": "v0.10.0-dev",
    "data_returned": 1,
    "implementation": {
      "maintainer": {
        "email": "cod-bugs@ibt.lt"
      },
      "name": "Crystallography Open Database",
      "source_url": "svn://www.crystallography.net/cod/trunk/cod/cgi-bin/optimade.pl@248412",
      "version": "v0.6.0"
    },
    "more_data_available": false,
    "query": {
      "representation": "/info/?"
    },
    "time_stamp": "2020-05-04T11:27:30Z"
  }
}
✖: http://www.crystallography.net/cod/optimade/info/ - deserialize_response - failed with error
	ValidationError: 3 validation errors for InfoResponse
	data
	  value is not a valid dict (type=type_error.dict)
	meta -> provider
	  field required (type=value_error.missing)
	meta -> implementation -> source_url
	  URL scheme not permitted (type=value_error.url.scheme; allowed_schemes={'https', 'http'})

[ml-evs]

As this issue has now been moved to the appropriate tracker, I think we can close it.

[merkys]

@ml-evs thanks a lot for the detailed report! I admit I still have to get down on the providers part of the specification. And yes, it's OK to close the issue, as it is caused by COD implementation of OPTIMADE.