In response to this; I am organising the REST API of an internet site venture.
I am returning the WP_Rest_Response
for regardless of which request in each doable finish, with an in accordance http standing code, and many others; it doesn’t matter what occurs within the request (If errors happen, I return a WP_Rest_Response
object with an in accordance error suggestions, and if the whole lot works, I return a WP_Rest_Response
with an in accordance optimistic suggestions).
The API Calls all work completely.
My downside now’s that, for instance your validate_callback
which you can present to your args
when utilizing register_rest_route
, fails. Indicating that any of your validations reported a failed validation with a variable.
This appears to, based on the supply code I’ve checked inside wp-includes/rest-api/class-wp-rest-response
, generate after which output a WP_Error
object, with actually all the particulars, explaining exactly why the request failed (On this case for instance that “parameter ‘x’ isn’t legitimate”).
Identical occurs for instance in case you have not supplied all the arguments you record as required
for a given endpoint.
My query now’s, is there some sort of wp filter or a hook to inform that on this case, we should always merely output the HTTP standing to the shopper, and no extra particulars? I simply really feel that it is pointless to clarify the place precisely a validation failed, in manufacturing code. Particularly as it is a security characteristic, I really feel it’s best to inform your potential attackers as much less as doable about your protection mechanisms, or no less than scale back the hints you present to a minimal.
The one factor that I may discover up to now on this sense is the _fields
parameter; however yeah this filter is about on the client-side and is thus straightforward to control. I do know that the linked web page says that it is not advisable to alter the responses; however I simply puzzled in the event that they have not ready a filter which you can scope to a customized REST namespace, or comparable..?