Hi Yunfeng, Thanks for this proposal. It's helpful to be able to customize REST handlers, so developers can easily expose a service of their own that accesses their plugin components running in the JobManager or inside a Flink job, like some RPC operator service.
However, I suppose that accessing a plugin needs a bridge from the REST handler to the internal component/service, but the bridge to the component itself is not included in this proposal, and we don't exactly know what bridge is needed. At this point, I think OperatorCoordinator is the most widely used plugin component, which does have the bridge. Other pluggable components like ShuffleService are rarely customized and also lack the bridge. In conclusion, for components without such a bridge, to implement a customized REST service, patches on Flink are still needed, so the proposal itself may only cover a narrow scene like OperatorCoordinator. Can you share the aiming scene and reevaluate whether we need a fully pluggable REST handler, or a specific handler that is needed? If you indeed need a service that accesses an OperatorCoordinator, maybe we can narrow down the proposal to an externally accessible coordinator handler. On Sat, Oct 10, 2026 at 4:16 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
