Hi Yunfeng, Thanks for narrowing the scope. Reusing the existing coordinator request path makes sense to me.
I have one question about the 404 contract for coordinators that do not accept external requests. `DefaultOperatorCoordinatorHandler` currently only checks whether the coordinator implements `CoordinationRequestHandler`. For example, `CollectSinkOperatorCoordinator` implements that interface but rejects anything other than `CollectCoordinationRequest` with `Preconditions.checkArgument`. With the proposed `IllegalArgumentException` mapping, an external request reaching it would appear to produce 400 rather than 404. Is 404 intended only for coordinators without `CoordinationRequestHandler`, or also for those that implement it but do not support `ExternalCoordinationRequest`? Could the integration tests explicitly cover an internal-only coordinator alongside an external-capable coordinator rejecting an invalid payload, so this distinction is clear? Best, Zhe Wang Yunfeng Zhou <[email protected]> 于2026年10月18日周日 20:58写道： > 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 > >
