gerlowskija commented on PR #4078: URL: https://github.com/apache/solr/pull/4078#issuecomment-3824257414
First off, thanks again for sharing this PR and tackling another v2 API! > Should we keep the URL path /node/system [...] This PR wrap the system info in "nodeInfo" [...] the "node" field should be named "name" [...] a lot of changes, breaking changes I agree with some of your concerns about the "cosmetics" of the request and API-response as they are today. We're free to change v2 APIs and their responses as much as we'd like. But v1 APIs are required to be backwards-compatible: breaking changes can only occur on major-version upgrades. That's not to say that v1 can't be changed, just that if v1 has a "breaking change" then it can only go to 'main', not branch_10x. So we've got some options depending on how much we care about updating v1 vs. v2-only. What we've done in a few places elsewhere is make whatever improvements we want to the v2 response format, and then if the v1 codepath calls v2 code have the v1 code do some manual massaging to reshape the response into something that meets backwards compatibility. It's not pretty, but it meets the requirements and is code that will eventually go away when we are able to deprecate and remove some of these v1 endpoints. So that's probably what I'd recommend for these sort of smaller response-changes. I'm somewhat tempted, as I read your comments, to suggest overhauling this endpoint entirely and making it look radically different in our v2 API. Something like splitting it up into a few smaller paths, like `/node/jvm`, `/node/resources`, `/node/version`, etc. But it's probably better to get things ported over to v2 in the current format and then reevaluate? Idk - curious if you have any thoughts on that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
