Raise 404 if object not found

[iamareebjamal]

Instead of raising 404 if an object is not found, the library tries to serialize it using the schema, hence causing marshmallow-code/marshmallow-jsonapi#302

What is the use case of this behaviour? Why not raise ObjectNotFound if object returned after get from data layer is None?

[mahenzon]

It's JSON:API spec https://jsonapi.org/format/
there was a related fix recently: #33

Here's the spec: https://jsonapi.org/format/#fetching-resources-responses-200

If the above article’s author is missing, then a GET request to that related resource would return:

HTTP/1.1 200 OK
Content-Type: application/vnd.api+json

{
  "links": {
    "self": "http://example.com/articles/1/author"
  },
  "data": null
}

[iamareebjamal]

That is only true for related resource AFAIK. For a single resource, it should return 404

404 Not Found
A server MUST respond with 404 Not Found when processing a request to fetch a single resource that does not exist, except when the request warrants a 200 OK response with null as the primary data (as described above).

[mahenzon]

To be honest, you are not the first one to ask this question
This time I made a bit more research and seems you are right and this has to be done another way
Here's an example from the playground

http://jsonapiplayground.reyesoft.com/v2/authors/101

HTTP/1.1 400 Bad Request
Content-Type: application/vnd.api+json

{
  "errors": [
    {
      "status": "404",
      "title": "Resource not found",
      "detail": "Resource Author `101` not found.",
      "meta": null
    }
  ]
}

but this one returns status code 400, which is a bit confusing too 🤔

also, there's an example with filter[x]=1,3 where = is used as in_ filter and it means x is one of [1, 3]. (#22). I think we have to do it this way: if value on the backend is not a collection type (not an ARRAY), but is an int or str, we should replace eq filter with in_ and parse incoming data as a list, not as a single value.

These are breaking changes, I suggest planning it for v1.1.0
@Znbiz

[iamareebjamal]

Yes, I was confused because we were using our fork https://github.com/fossasia/flask-rest-jsonapi and want to switch to this maintained repo. So, I switched to this maintained repo and I am trying to bridge the gaps by either writing plugins or reporting issues if it is an incompatible upstream bug. In this case, I cannot fix it with a plugin and it is actually an issue with the upstream library as well.

The example with 400 response code is strange because there is no error in the request at all.

I would love to contribute and bridge the gap with more features and making it spec compliant, so that I can switch the library to single version rather than maintaining another fork which will eventually become outdated. For example, I have issues with nested sorting and flipped source and detail in errors which are fixed in the above repo. I will open relevant issues and you can comment whether those come in the scope of this repo or not. Hopefully, this will become the de-facto maintained jsonapi repo instead of dozens of unmaintained one.

Thanks for taking the initiative

[iamareebjamal]

Also, there are a lot of examples without test cases which fail on actual implementation, so I would also add a few more tests to cover those implementation, e.g., #34

[Znbiz]

I support.
This needs to be implemented.
You also need to raise this issue here https://github.com/json-api/json-api/issues to be included in the spec.

[iamareebjamal]

Already a part of spec https://jsonapi.org/format/#fetching-resources-responses-404
json-api/json-api#298 (comment)
katharsis-project/katharsis-framework#272

[Znbiz]

@iamareebjamal , you're right.
Regarding the inclusion in the specification, I meant this:

also, there's an example with filter[x]=1,3 where = is used as in_ filter and it means x is one of [1, 3]. (#22). I think we have to do it this way: if value on the backend is not a collection type (not an ARRAY), but is an int or str, we should replace eq filter with in_ and parse incoming data as a list, not as a single value.

These are breaking changes, I suggest planning it for v1.1.0
@Znbiz

[mahenzon]

@iamareebjamal great to hear that! We welcome any initiative and are happy to deliver any fixes and improvements!
Thanks for being involved 🎉