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 >
