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
Handle some create and update errors in the REST adapter. #476
Conversation
Not sure why Travis failed there. The whole test suite works for us in the browser and from the command line. |
It is actually failing jshint because of another commit: 90c253d |
This seems fine but I think we were planning for something more comprehensive to do error handling. Nevertheless, this might be ok in the short term. @wycats? Also, the JSHint failure has been fixed. |
@elliterate if you DRY up the error callback, this looks good to go. |
* 422 Unprocessable Entity Transitions the record to the invalid state. Assumes the server has responded with `{errors: {...}}` and sets them on the record. * All other status codes Transitions the record to the error state. This is limited to only single, non-bulk creates/updates.
The error callback is now DRY. |
Handle some create and update errors in the REST adapter.
Is there plans (soon) to add support for 422 (?) on deletes? How should it be handled if an object shouldn't be allowed to be deleted? |
If the object is not allowed to be deleted, wouldn't 403 be more appropriate response? |
You are right. 403 would be better. On Apr 25, 2013, at 3:12 PM, "Adam Cigánek" notifications@github.com If the object is not allowed to be deleted, wouldn't 403 be more — |
422 Unprocessable Entity
Transitions the record to the invalid state. Assumes
the server has responded with
{errors: {...}}
andsets them on the record.
All other status codes
Transitions the record to the error state.
This is limited to only single, non-bulk creates/updates.