[wp-trac] [WordPress Trac] #46238: REST API: Allow conditional field registration

[WordPress Trac]

#46238: REST API: Allow conditional field registration
-------------------------+------------------------------
 Reporter:  dmsnell      |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by dmsnell):

 thanks for the feedback @mmtr86

 > I wonder however what implications this may cause to the schema.

 I did some checking to see if I could explore your prompt more. in the
 process I noticed an oddity and a salient point about schema. I also noted
 that it was difficult for me to find clear documentation on the schema
 side of the API - particularly to understand how this schema fits in with
 the overall shape of the response

 for one, I learned that I should be able to query the schema with a `GET`
 call to the API base…

 {{{#!bash
 curl 'http://localhost/wp-json/wp/v2/' | jq '.routes |
 ."/wp/v2/media/(?P<id>[\\\\d]+)" | .endpoints[0]'
 {
   "methods": [
     "GET"
   ],
   "args": {
     "id": {
       "required": false,
       "description": "Unique identifier for the object.",
       "type": "integer"
     },
     "context": {
       "required": false,
       "default": "view",
       "enum": [
         "view",
         "embed",
         "edit"
       ],
       "description": "Scope under which the request is made; determines
 fields present in response.",
       "type": "string"
     }
   }
 }
 }}}

 …but the schema for my fields didn't come though. interestingly enough
 they come through for the update endpoints.
 {{{#!bash
 curl 'http://localhost/wp-json/wp/v2/' | jq '.routes |
 ."/wp/v2/media/(?P<id>[\\\\d]+)" | .endpoints[1]'
 {
   "methods": [
     "POST",
     "PUT",
     "PATCH"
   ],
   "args": {
     …
     "vp_guid": {
       "required": false,
       "description": "Some GUID",
       "type": "string"
     },
     …
   }
 }
 }}}

 It took me a while to figure out how to query the schema. This we do with
 an `OPTIONS` request.

 {{{#!bash
 curl -X OPTIONS 'http://localhost/wp-json/wp/v2/media/5' | jq '.schema
 .properties'
 {
   …
   "vp_guid": {
     "description": "Some GUID",
     "type": "string",
     "context": [
       "view",
       "edit"
     ],
     "required": false
   },
   …
 }
 }}}

 If I interpret the entire response schema as a JSON-Schema then I think it
 means that we're covered. Without that explicit `required => false`
 indicator it won't show up as not required, but at the same time my
 understanding of JSON-Schema is that unless a field is explicitly
 indicated as `required` then it's not required.

 In other words I don't think this carries any implications on the schema
 unless we've marked the field as `required => true`. If I take into
 consideration that it's less obvious how to even get the `GET` schema it
 seems to mark us even more safe. I don't understand the implications of
 the update endpoints though.

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