Unable to POST a Contact with null location and/or telephone

[AlexJoom]

I am unable to POST a Contact with a NULL location and/or telephone on a local branch of the v1.3.20240308 API. Both of these properties are not required to be filled per spec.

This POST results in a 422 Unprocessable Entity:

{
  "platform": "ai4europe_cms",
  "platform_resource_identifier": "user-1",
  "name": "ai4europe_cms_admin",
  "email": [
    "noreply@ai4europe.eu"
  ],
  "location": null,
  "organisation": null,
  "person": null,
  "telephone": null,
  "aiod_entry": {
    "editor": [],
    "status": "published"
  }
}

Response:

HTTP/1.1 422 Unprocessable Entity
Server: nginx/1.25.2
Date: Fri, 15 Mar 2024 13:27:03 GMT
Content-Type: application/json
Content-Length: 217
Connection: close

{
  "detail": [
    {
      "loc": [
        "body",
        "location"
      ],
      "msg": "none is not an allowed value",
      "type": "type_error.none.not_allowed"
    },
    {
      "loc": [
        "body",
        "telephone"
      ],
      "msg": "none is not an allowed value",
      "type": "type_error.none.not_allowed"
    }
  ]
}

In contrast, this POST, with location and telephone properties omitted, is successful:

{
  "platform": "ai4europe_cms",
  "platform_resource_identifier": "user-1",
  "name": "ai4europe_cms_admin",
  "email": [
    "noreply@ai4europe.eu"
  ],
  "organisation": null,
  "person": null,
  "aiod_entry": {
    "editor": [],
    "status": "published"
}

Response:

HTTP/1.1 200 OK
Server: nginx/1.25.2
Date: Fri, 15 Mar 2024 13:53:58 GMT
Content-Type: application/json
Content-Length: 16
Connection: close

{"identifier":2}

Of course, properties with NULL values can easily be stripped by the client before POST, so a workaround is possible, but on the other hand I was wondering why a NULL value is accepted for the "person" property (expecting an integer), but on the other hand its rejected as a location or telephone (both expecting arrays) -especially when the API seems to correctly interpret the NULL as "none".

[PGijsbers]

The difference here is in the arity of the relationship. Location and telephone (and e-mail) are 0..n relationships, which means they expected lists. To indicate a contact has none, it expects an empty list ([]) instead of null. When the field is omitted, the default is [] and not null. By contrast, the Person is a 0..1 relationship, which means that it expects an integer or null (the fact that it allows null is derived from the fact that the property is not required). This explains the behavior you are seeing.

We should definitely provide better error messages here (#85), but I do not think we should allow null as valid input. For example, here it should read something along the lines of:

"null was provided as value, but the field expects a list. If there are no associated entities, specify an empty list instead ([])"

Does this address the issue, and do you agree with the resolution?

[AlexJoom]

Υes we agree. Indeed, a better error message would be very helpful. Thank you!

[PGijsbers]

@Taniya-Das Would you be able to have a look at this? We just want the error message to be more user friendly, that's all.