Hi Mickael, Thanks for the review, I updated the KIP.
1- Replaced N / N+1 with concrete releases: introduced changes in 4.x((not sure if we can make it into 4.4), removal in the next major, 5.0. 2- Added return types: GET /connectors → List<String> GET /connectors-details → Map<String, ConnectorDetails>, a new typed entity with optional status (ConnectorStateInfo) and info (ConnectorInfo). This gives a concrete OpenAPI schema instead of a free-form map. Wire format is unchanged — unrequested fields are omitted from the JSON rather than serialized as null, so it's byte-for-byte identical to today's ?expand=... Regards, Nilesh On Mon, Jul 6, 2026 at 9:45 AM Mickael Maison <[email protected]> wrote: > > Hi, > > Thanks for the updates. > > Can we clarify the N, N+1 releases? We only do removals in major > versions, so N+1 is the next major release (Kafka 5.0 at the moment). > Even though it's internal, I think the KIP should describe the Java > types that will be returned in the next major release for the GET > /connectors and GET /connectors-details endpoints, as they determine > what the OpenAPI spec will look like. > > Thanks, > Mickael > > On Thu, May 14, 2026 at 2:52 PM nileshkumar3 <[email protected]> wrote: > > > > 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 > > > > >
