[wp-trac] [WordPress Trac] #50244: Add bulk operation support to the Rest API

[WordPress Trac]

#50244: Add bulk operation support to the Rest API
-----------------------------+--------------------------------
 Reporter:  andraganescu     |       Owner:  TimothyBlynJacobs
     Type:  feature request  |      Status:  assigned
 Priority:  high             |   Milestone:  5.5
Component:  REST API         |     Version:  4.4
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  performance
-----------------------------+--------------------------------

Comment (by TimothyBlynJacobs):

 @zieladam Yep, but to clarify the bulk of the validation happens by
 providing a schema for the properties which validates and sanitizes
 according to the provided JSON schema. When the validation isn't possible
 to do just with a schema, the goal is to provide a `validate_callback`,
 see for instance `check_template()` in the posts controller. But we don't
 do this consistently, for instance `handle_status_param()` could be
 implemented as a `validate_callback` and `sanitize_callback`. The majority
 of those other checks could also be refactored to be callbacks as well.

 The menus controller is separately doing validation against the schema
 which should be dropped,
 https://github.com/WordPress/gutenberg/blob/2881f84896cace4cc1828774c8e09252d9e67e39/lib
 /class-wp-rest-menu-items-controller.php#L368. And has some things that
 can be expressed in the schema,
 https://github.com/WordPress/gutenberg/blob/2881f84896cace4cc1828774c8e09252d9e67e39/lib
 /class-wp-rest-menu-items-controller.php#L516.

 So I think starting with the menus controller, any validation checking
 that happens in `prepare_item_for_database` that can be refactored to have
 a `validate_callback` should be starting with the checks that happen on a
 single parameter. Something to note, is that applying a custom
 validate_callback skips the schema validating since that is implemented
 just as the default validate callback. So in that case, if the validation
 is supposed to be additive, then we should call
 `rest_validate_request_arg()` in the top of the new validate_callback and
 bail out if that returns a `WP_Error` instance.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50244#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform