[wp-trac] [WordPress Trac] #56546: Permit queries by ID in /search REST endpoint
WordPress Trac
noreply at wordpress.org
Sun Sep 11 20:49:42 UTC 2022
#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
More information about the wp-trac
mailing list