[wp-trac] [WordPress Trac] #64926: REST API: GET requests fail object/array schema validation when params are JSON-serialized strings

[WordPress Trac]

#64926: REST API: GET requests fail object/array schema validation when params are
JSON-serialized strings
-------------------------+-------------------------------------------------
 Reporter:  dsmy         |       Owner:  (none)
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, php-
                         |  compatibility
-------------------------+-------------------------------------------------

Comment (by liaison):

 Replying to [comment:18 westonruter]:
 > Replying to [comment:15 liaison]:
 > > While PHP's bracket notation (?user[name]=Bob) exists, it's not the
 ideal tool for modern decoupled clients or AI-agent integrations (like
 MCP) for several reasons:
 > >
 > > Lossy Encoding: As noted by @zieladam, bracket notation collapses
 types (e.g., boolean false becomes string "false", null becomes empty
 string), which breaks logic for strict schemas like block attributes.
 >
 > I'm not saying that adding JSON parsing of fields is a bad idea, but as
 I shared in [comment:13 my comment above], it's not necessarily a lossy
 encoding. The problem with your example endpoint is that it lacks a schema
 for the `object` properties. If I modify your example as follows to add
 `properties`:
 >
 > {{{#!php
 > <?php
 > add_action( 'rest_api_init', function () {
 >       register_rest_route( 'my-test/v1', '/schema-test', [
 >               'methods'  => 'GET',
 >               'callback' => fn( WP_REST_Request $req ) => [ 'success' =>
 true, 'data' => $req->get_param( 'config' ) ],
 >               'args'     => [
 >                       'config' => [
 >                               'type' => 'object',
 >                               'properties' => [
 >                                       'id' => [
 >                                               'type' => 'integer',
 >                                       ],
 >                                       'active' => [
 >                                               'type' => 'boolean',
 >                                       ]
 >                               ],
 >                       ]
 >               ],
 >       ] );
 > } );
 > }}}
 >
 > Before adding `properties`, a request to `/wp-json/my-test/v1/schema-
 test?config[id]=123&config[active]=true` would return:
 >
 >
 > {{{#!json
 > {"success":true,"data":{"id":"123","active":"true"}}
 > }}}
 >
 > But after adding `properties` then it returns the expected types:
 >
 > {{{#!json
 > {"success":true,"data":{"id":123,"active":true}}
 > }}}

 Thanks for the detailed example, @westonruter.

 You're right that defining properties in the schema handles type
 conversion perfectly for bracket notation. It's a solid part of the REST
 API's validation logic.

 The main goal here is to improve the "Decoupled Developer Experience."
 While bracket notation works, it gets messy with deeply nested objects or
 when using dynamic additionalProperties where we can't pre-define types.
 Supporting JSON in GET requests provides a cleaner, more reliable
 interface for modern JS clients and AI tools. It lets them pass objects
 directly without having to manually encode everything into PHP-style
 bracket strings.

 For example, a deeply nested structure like ?a[b][c][d][e]=value can
 quickly approach URL length limits and is much more complex for frontend
 developers to construct than a simple ?config={...}.

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