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
