Open AdrianVandierAst opened 4 years ago
So the spec also says:
null is only an appropriate response when the requested URL is one that might correspond to a single resource, but doesn’t currently.
Note: Consider, for example, a request to fetch a to-one related resource link. This request would respond with null when the relationship is empty (such that the link is corresponding to no resources) but with the single related resource’s resource object otherwise
I assume this is where what the current implementation is based on. GET /persons/3
is "a URL that might correspond to a single resource, but doesn’t currently" and also "a single resource that does not exist", so I'm not sure which is correct. Presumably it's the former, since it's not the same situation as a relationship for an existing object.
If it ends up that this implementation is wrong, feel free to also put in your PR to https://github.com/TMiguelT/flapison, since I can guarantee that I'll review and merge it, whereas I can't say the same for this repo.
When a single resource is not found, the api responds a 200 OK response with {"data": null}. There is even a test that checks that:
test_get_detail_object_not_found
.But the json:api is explicit about that:
The 200 OK response is only when the resource is a to-one relationship.
The 200 OK response for simple resource detail queries is intended for a reason i don't understand ? If not, I will create a pull request.