We can introduce a V2 API at any point while supporting V1.
Given that this has been the case for years I'm not entirely convinced
that the pain points are large enough to push anyone to pursue that.
( in particular, providing an _entire_ API and not just a few special
endpoints (which would also be possible and not necessarily bad!))
I would need more context to comment on the stack trace issue to
understand what the problem is and how it could be improved.
Anyhow, that'd be a way larger effort, while most of these smaller REST
API are mostly for maintenance reasons, which given that the V1 API must
be supported for all of 2.x still make sense. (and even if V2 lands in
2.0, having a WebUI-specific API isn't necessarily bad either)-
A separate thread on the topic could be very useful though!
On 20/07/2023 00:51, Austin Cawley-Edwards wrote:
It doesn't need to be part of the Flink 2.0 release perse, but starting to
wonder if we'd get more bang for our buck if we started fresh with a v2
REST API vs. one-off cleanups of the current v1 API. @Chesnay Schepler
<ches...@apache.org> -- wdyt?
The v1 REST API seemed to grow naturally from its original use case of
supporting the Web UI iiuc, but now another of the core use cases is
operational (e.g., supporting the K8s Operator). For the operational use
case, it is clear that this wasn't the original design goal (e.g., cases
exist that require parsing the included Java stack trace to determine what
to do). Maybe @Gyula Fóra <gyula.f...@gmail.com> also has some
experience/suggestions to share on if this would be valuable. (also happy
to start a new thread, sorry for co-opting this one)
Austin
