Opened 9 years ago
Closed 9 years ago
#34551 closed enhancement (fixed)
Change API error response to focus on singular errors
Reported by: | rmccue | Owned by: | johnbillion |
---|---|---|---|
Milestone: | 4.4 | Priority: | normal |
Severity: | normal | Version: | 4.4 |
Component: | REST API | Keywords: | has-patch has-unit-tests |
Focuses: | Cc: |
Description
(Migrating https://github.com/WP-API/WP-API/issues/1473 here.)
Basically: right now, the API returns a list of objects on error:
[ { "code": "rest_no_route", "message": "No route was found matching the URL and request method", "data": { "status": 404 } } ]
This is because under the hood, WP_Error
holds multiple errors. Most people don't use this functionality at all, and this complicates error handling on the client site.
This is p late, but still early enough to change this IMO. Needs sign-off though, since it's technically a BC break, and it cuts out some potential use cases of WP_Error
Attachments (2)
Change History (14)
#2
in reply to:
↑ 1
@
9 years ago
- Keywords has-patch added
Replying to dd32:
I'd almost expect it to return the "primary" error object, with any additional errors available in an extra sub-key
Agreed, it's a bit non-obvious there.
An example use-case for where multiple errors are returned would significantly help in deciding if we do need to retain this though.
There's a few potential cases for this. One of the key ones might be multiple validation errors, so e.g. you're trying to create a post, but a) you're not authorised, and b) you sent an invalid post date.
Attached 34551.diff as an initial patch at this.
This ticket was mentioned in Slack in #core-restapi by rmccue. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-restapi by rmccue. View the logs.
9 years ago
#8
@
9 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
WP_REST_Response::as_error()
needs an update.
Since this is a BC break, if we're going to do it, it has to happen now obviously.
I'd almost expect it to return the "primary" error object, with any additional errors available in an extra sub-key
An example use-case for where multiple errors are returned would significantly help in deciding if we do need to retain this though.