Thanks for flagging things like this on the list and taking the lead with decision making.
The only alternative I can think of is urlEncoding a path to put it in a @PathParam, but I don't think that would be a better solution as it easily causes encode/decode confusion and URL paths that are both harder to read and contstruct by hand. Those concerns could be helped somewhat by a convention to replace shashes with underscores or similar, i.e. .../config/requestHandlers/_update_json_docs But I don't like this any better than the &componentName @QueryParam solution. Jan > 20. okt. 2026 kl. 21:55 skrev Jalaz Kumar <[email protected]>: > > Hello All > > We went ahead with the proposed approach & have merged the PR: > https://github.com/apache/solr/pull/5168 into main today. > Let me know still if someone has any other ideas around, happy to take > those suggestions as follow-up PR & improve this further. > > Regards > > On Sat, Oct 17, 2026 at 1:17 AM Jalaz Kumar <[email protected]> > wrote: > >> Hello >> >> Quick note on the Config V2 API GET .../requestHandlers design in the PR: >> https://github.com/apache/solr/pull/5168, specifically why the handler >> name is still @QueryParam (?componentName=...) rather than being @PathParam >> which we are adopting for making the V2 APIs more RESTful. >> >> For searchComponents & responseWriters we have migrated V2 GET configs >> from QueryParam to PathParam & now we have: >> >> - GET /api/collections/{collection}/config/searchComponents/{name} >> - GET /api/collections/{collection}/config/queryResponseWriters/{name} >> >> This kind of notation in V2 APIs works for them as these names are single >> path segments (spellcheck, xslt, etc) but requestHandler names are >> different. They are themselves paths like /select, /update/json/docs, >> /admin/ping etc. >> >> Thus we propose to keep V2 APIs in the same format as it is right now due >> to this limitation. >> >> *GET >> /api/collections/{collection}/config/requestHandlers?componentName=/update/json/docs* >> >> If anyone has other ideas for making this path more RESTful without >> breaking names that contain "/", We'd really appreciate the input if >> there's a cleaner approach we're missing. >> >> -- >> Regards >> Jalaz Kumar >> > > > -- > Regards > Jalaz Kumar --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
