Hi all, Picking this up in the original thread: my earlier reply landed in a separate thread by mistake, so the discussion is split in two.
FLIP-617 is now narrowed to a single public REST endpoint that delivers an opaque JSON payload to an operator's coordinator, as Gen suggested. The page has been retitled and rewritten: https://cwiki.apache.org/confluence/x/C6rwGg Zhe Wang asked whether a coordinator that rejects the request type should answer 400 or 404, and I replied here: https://lists.apache.org/thread/yqd3c0zfoqtw1ohntf0o76kbrg8flmf5 Please continue further discussions in this thread. Thanks, Yunfeng Zhou On Sat, Oct 10, 2026 at 4:15 PM Yunfeng Zhou <[email protected]> wrote: > > Hi all, > > I'd like to start a discussion on FLIP-617: Support Pluggable REST Handler > Extensions. > > Currently, Flink's JobManager exposes a REST endpoint as the control-plane > entry point for cluster and job operations, but adding a new REST operation > requires registering it inside Flink core. For components that are developed > and released separately from Flink, this leaves only two unattractive > options: maintain a Flink fork, or add component-specific APIs to Flink core > and couple the component's release cycle to Flink's. Flink already offers > extension mechanisms for areas such as file systems, metrics, and security, > but the REST endpoint has no general mechanism for a component to contribute > its own routes. > > This FLIP proposes a pluggable, cluster-level extension mechanism that lets a > trusted component register its own JobManager REST routes, reusing Flink's > existing REST routing, versioning, leader retrieval, and lifecycle, while > keeping the component's REST resources and runtime semantics outside Flink > core. The mechanism is intended to be experimental and additive, and to leave > the behavior of existing REST endpoints unchanged. > > FLIP page: > https://cwiki.apache.org/confluence/x/C6rwGg > > Feedback on any part is welcome. > > Thanks, > Yunfeng Zhou
