Thanks Raj for reviewing this. The KIP already covered documentation. However, I've updated it so it’s explicit that we will update the public Connect REST documentation and OpenAPI for the expand deprecation, the warning window, and new GET /connectors-details.
Thanks, Nilesh On Tue, Apr 14, 2026 at 11:17 AM raj kumar <[email protected]> wrote: > > Everything looks good to me . I would like to suggest updating the > documentation for deprecating the functionality of query parameter "expand" > as well. This will ensure that the client side also get informed about the > changes . > > Thanks , > Raj > > On Wed, Apr 8, 2026 at 11:52 PM Mickael Maison <[email protected]> > wrote: > > > Hi, > > > > Thanks for the KIP. > > > > MM1: As mentioned in the KIP, the new endpoint GET > > /connectors/expanded would collide with GET /connectors/<CONNECTOR> if > > a connector is named expanded. While it's somewhat unlikely it's still > > not ideal, and ironically it defeats the original goal of the KIP > > which is to have a single response type per endpoint. With the current > > proposal you get different responses whether the expanded connector > > exists or not. Have you considered alternatives? For example GET > > /connectors-details? > > > > MM2: I'm unsure we need to return HTTP 400 in the next major release > > if expand is set. Today none of the endpoints return 400 if you pass > > extra query parameters. Do you have a specific motivation for that > > behavior? > > > > MM3: Can you provide concrete examples of responses for the new > > endpoint with the various options? For example is the "status" field > > present when using expand=info? > > > > A large portion of the KIP reads like it's coming from a LLM. This is > > not an issue per se, but there's a lot of duplication and unnecessary > > noise that make this simple KIP not a trivial read. > > > > Thanks, > > Mickael > > > > On Wed, Apr 8, 2026 at 7:08 AM nileshkumar3 <[email protected]> > > wrote: > > > > > > Hi all, > > > > > > I'd like to start a discussion on KIP-1315, which proposes splitting the > > connector listing and expanded views in the Connect REST API. > > > > > > KIP: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1315%3A+Split+Connector+Listing+and+Expanded+Views+in+the+Connect+REST+API > > > > > > JIRA: https://issues.apache.org/jira/browse/KAFKA-20392 > > > > > > Problem: The current GET /connectors endpoint changes its response > > depending on whether the expand query parameter is present — returning a > > JSON array of names without it, and a JSON object map with it. This creates > > a non-uniform API contract that causes issues for generated clients > > (OpenAPI / strongly typed clients), API consumers expecting stable schemas, > > and long-term maintainability. > > > > > > Proposal: Introduce a new GET /connectors/expanded endpoint dedicated to > > expanded connector metadata, and phase out the expand parameter on GET > > /connectors over two releases: > > > > > > Release N: GET /connectors/expanded is introduced. GET > > /connectors?expand=... continues to work but logs a deprecation warning > > pointing to the new endpoint. > > > Release N+1: GET /connectors?expand=... returns HTTP 400, directing > > users to GET /connectors/expanded. > > > This gives every endpoint a single, predictable response schema while > > preserving all existing capabilities and providing a clear migration path. > > > > > > I'd appreciate any feedback on the approach, the deprecation timeline, > > or the API design. Please refer to the KIP wiki page for full details > > including compatibility, test plan, and rejected alternatives. > > > > > > Thanks, > > > Nilesh > >
