Hi All, I have addressed the previous feedback and updated the KIP accordingly:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1315%3A+Split+Connector+Listing+and+Expanded+Views+in+the+Connect+REST+API I would appreciate any final review comments. If there are no major concerns, I plan to initiate the voting thread next week. Thanks, Nilesh On Thu, Apr 16, 2026 at 10:02 PM nileshkumar3 <[email protected]> wrote: > > 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 > > >
