Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can not handle 204 no content for updating resources. #143

Open
aars opened this issue Mar 8, 2017 · 2 comments
Open

Can not handle 204 no content for updating resources. #143

aars opened this issue Mar 8, 2017 · 2 comments

Comments

@aars
Copy link
Collaborator

aars commented Mar 8, 2017

http://jsonapi.org/format/#crud-updating-responses-204

204 no content is a valid response, but it does not trigger any update on the Resource that was updated (since deserialize has nothing to do).

@aars
Copy link
Collaborator Author

aars commented Mar 9, 2017

This is mostly an issue in https://github.com/pixelhandler/ember-fetchjax. Which decides that a 204 response should have it's own handler that returns an empty string. The regular success handler is not called, and the resolved promise shows no sign of a 204 response (an empty string as response is not a good way to check if this was a 204).

Which means there is no way to single out these requests and handle the updates/state on the just-updated-resource.

To fix this, I have sent in this PR on ember-fetchjax.

That PR will break EJR however. I have some EJR changes/patches coming up to (hopefully) completely fix relationship tracking which rely on that ember-fetchjax PR though.

@pixelhandler
Copy link
Owner

@aars If I recall, I added the special "No Content" handler to accommodate behavior from JSONAPI::Resources gem in the Rails app I worked on while developing the library. Which should be based on this part of the spec:

Note: If a 204 response is received the client should consider the resource object sent in the request to be accepted by the server, as if the server had returned it back in a 201 response.

I guess I figured an empty String '', was better then an undefined or null response. But yeah sounds like we should revisit that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants