Hi Gen, You were right, and I've narrowed FLIP-617 the way you suggested — to an externally accessible coordinator handler. It delivers one opaque JSON payload to the addressed operator's coordinator and returns the coordinator's answer.
Your point about the bridge is what the design rests on: rather than an SPI that needs a bridge handed to it, the endpoint reuses the delivery path Flink already has. Why the general SPI was dropped is written up under "Rejected Alternatives". The page has been retitled and rewritten for the narrowed scope: https://cwiki.apache.org/confluence/x/C6rwGg Thanks, Yunfeng Zhou On 2026/10/14 03:43:56 Gen Luo wrote: > 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 >
