#41549 closed enhancement (wontfix)
REST API: Use `wp.apiRequest` helper in `wp.api` Backbone client
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | REST API | Keywords: | needs-patch needs-unit-tests dev-feedback |
Focuses: | javascript, administration, rest-api | Cc: |
Description
Follow-up to #40919. The wp-api.js
Backbone client should use wp.apiRequest
to do its API calls. This may be accomplished through overriding Backbone.ajax
or through a change in the wp-api.js
code.
This will allow client-side code to override or modify all WP REST API calls in a single, centralized place.
cc @adamsilverstein for your thoughts on the best way to achieve this.
Attachments (1)
Change History (9)
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
7 years ago
This ticket was mentioned in Slack in #core-restapi by kadamwhite. View the logs.
7 years ago
#5
@
7 years ago
@adamsilverstein I think most of the value in this change is in having wp-api.js
use buildAjaxOptions
. I could have explained the reasoning better in the ticket, but here is a good example of how this could be helpful: #42807
I am not sure how to handle users overriding Backbone.ajax
. It would be good to see an example of this in WordPress context, otherwise I think it is probably not very common.
@jnylen0 - 41549.diff is a first pass at this.
Backbone.ajax
withwp.apiRequest.transport
- I looked at replacing first withwp.apiRequest
, however I don't think we need the additional logic inbuildAjaxOptions
and this might break something.wp.apiRequest.transport
for testingNot sure I like this - my concern here is that Backbone authors are used to the idea of being able to override
Backbone.ajax
to use an alternate method, for example this native implementation. This would actually break that (for the client), requiring that they overridewp.apiRequest.transport
instead.Punting for now for further consideration.