Allow all types of JSON API relationships

[merkys]

Currently the validator insists on list-only representations of relationships:

✖: https://www.crystallography.net/cod-test/optimade/structures?page_limit=5 - deserialize_response - failed with error
	ValidationError: 52 validation errors for ValidatorStructureResponseMany
[snip]
	data -> 0 -> relationships -> references -> data
	  `data` key in a relationship must always store a list. (type=value_error)
[snip]

In #397 (comment) @ml-evs and I have agreed that the specification does not limit relationship representations to lists only. Thus both of the following cases should be accepted as valid (citing @ml-evs fine examples):

• Without the intermediate list:

      "relationships": {
        "references": {
          "data": {
            "id": "1000000",
            "type": "references"
          }

• With the intermediate list:

      "relationships": {
        "references": {
          "data": [
            {
                "id": "1000000",
                "type": "references"
            }
          ]

[CasperWA]

I don't agree with this on the face of it.
In accordance with the JSON API specification there is a clear difference between to-one and to-many relationships. There are even conditions only applying to one and not the other (like pagination).
Since a structure may have several references related to it, it is clearly a to-many relationship, hence the value for the references relationships should be a list, empty of otherwise, if included.

However, if you understand the specification differently, please try to clarify.

[merkys]

In accordance with the JSON API specification there is a clear difference between to-one and to-many relationships. There are even conditions only applying to one and not the other (like pagination).

Indeed.

Since a structure may have several references related to it, it is clearly a to-many relationship, hence the value for the references relationships should be a list, empty of otherwise, if included.

After consulting JSON API and OPTIMADE specifications yet once more, I now lean towards thinking the same. Thanks for explanation!

[ml-evs]

Just my two cents, I agree that to-many relationships were the aim of the specification (and would be my preferred choice for sure), but I'm not sure this is so clear cut in the specification as it stands. The spec just defers to the overall JSON:API relationships definition which contains the sentence:

Relationships may be to-one or to-many.

I would be in favour of adding a note to the specification that restricts our relationships to always be to-many.

[CasperWA]

Just my two cents, I agree that to-many relationships were the aim of the specification (and would be my preferred choice for sure), but I'm not sure this is so clear cut in the specification as it stands. The spec just defers to the overall JSON:API relationships definition which contains the sentence:

Relationships may be to-one or to-many.

I would be in favour of adding a note to the specification that restricts our relationships to always be to-many.

Sure.
I think the intention in that sentence from the JSON API spec, however, is to reference the previous relationships resources can have, especially one-to-one or one-to-many.
But a clarification would sure be good 👍

[merkys]

I would not restrict to-many relationships altogether. I would leave sentence "Relationships may be to-one or to-many" as it is (because in the future we may want that for one reason or another), but clarify that references relationship is always to-many.