[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:  needs-patch  |     Focuses:  javascript, rest-api, php-
                         |  compatibility
-------------------------+-------------------------------------------------

Comment (by westonruter):

 Replying to [comment:8 zieladam]:
 > In any case, transforming arbitrary JSON objects into the bracket
 notation is lossy. There's to way to distinguish between `null` and
 `undefined`, or string `"false"` and boolean `false`, string `"10"` and
 number `10`, an array `["hello"]` and an object `{0: "hello"}` etc. It's
 just a wrong tool for encoding arbitrary JSON structures as they won't
 decode to the initial input. In other words,
 `decode_from_brackets(encode_as_brackets(data)) !== data`.

 Nevertheless, the REST API sanitization should be handling this in most
 cases. For example, if you have a nested property which is defined as an
 `int` in the schema, but you the property via `user[age]=21` then the
 string `"21"` will be recognized as an integer via `rest_is_integer()` and
 `rest_sanitize_value_from_schema()` will cast it to an `int`. The same
 goes for booleans. Since `undefined` can't be represented in JSON, then
 this wouldn't be a problem. So I think for //most// of the time, it would
 not be lossy.

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