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
