[wp-trac] [WordPress Trac] #56546: Permit queries by ID in /search REST endpoint

[WordPress Trac]

#56546: Permit queries by ID in /search REST endpoint
-------------------------+------------------------------
 Reporter:  kadamwhite   |       Owner:  kadamwhite
     Type:  enhancement  |      Status:  accepted
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  rest-api
-------------------------+------------------------------
Changes (by kadamwhite):

 * owner:  (none) => kadamwhite
 * status:  new => accepted


Comment:

 One thing about supporting `include` and `exclude` means that it prevents
 us from ever having a search controller that would allow searching across
 multiple object types ( terms and posts for instance ) in the same search
 request. I think it us unlikely we'll ever be able to support this,
 however. So I don't think that unlikely possibility should block landing
 this feature.

 While I concur that building such a controller—at least in core—is
 unlikely, I'm not sure I entirely agree with your conclusion. If we did
 end up with such a controller, as a consumer of it I would expect that if
 I pass `include=12`, and somehow have both a post with ID 12 and a term
 with ID 12 in my available results set, I would get both of those back in
 the list and would have to differentiate them by subtype. The reason we
 don't have any controller that behaves this way in core is because that
 would be confusing and deviate from how we expect a REST API to behave,
 but to me it would be "correct" in terms of what the user was asking for.

 All that said, you're right, we have no such controller and it seems
 highly unlikely we'd add one. :)

  We aren't really consistent about [how we reference request properties]
 throughout the search handlers already

 Good point. I missed that inconsistently when this controller went in, and
 definitely agree it's confusing. It's not clear why the authors of this
 controller decided to abstract the param string names into constants when
 it's not done elsewhere in the API.

 To maintain as much cross-controller consistency as possible, I agree we
 should stick to the way we do this in other controllers, which uses the
 inline string literals.

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