Re: [Discussion] Move DolphinScheduler Api V2 Forward

[Rick Cheng <ri...@gmail.com>]

Thanks Yifan for bringing this up. This is meaningful and long-term work,
and I'm also willing to participate and contribute.

Best Regards,
Rick Cheng


Jay Chung <zh...@gmail.com> 于2023年10月31日周二 09:49写道：

> +1 for this and thanks to Yifan for bringing this up.
> we should continue API refactoring
>
> On Mon, Oct 30, 2023 at 6:12 PM tracehh <sz...@163.com> wrote:
> >
> > +1
> >
> >
> > ---- Replied Message ----
> > | From | SbloodyS<zi...@apache.org> |
> > | Date | 10/30/2023 18:05 |
> > | To | <de...@dolphinscheduler.apache.org> |
> > | Subject | Re: [Discussion] Move DolphinScheduler Api V2 Forward |
> > Thanks Yifan for starting this discussion. I'm very happy that there are
> > still people who want to continue this improvement. I'm big +1 on this.
> >
> > --
> > Best Wishes
> > ZiHao
> >
> > Chufeng Gao <ch...@gmail.com> 于2023年10月30日周一 17:40写道：
> >
> > Thanks Yifan for starting this discussion. I'm +1 to the refactoring.
> >
> > Best Regards,
> >
> > Chufeng (Eric) Gao
> >
> >
> > On Sun, Oct 29, 2023 at 9:32 AM 孙一凡 <ab...@gmail.com> wrote:
> >
> > Hello developers,
> >
> > We have noticed that current Apis of Apache DolphinScheduler are not
> > convenient to use and
> > there have been dozens of users (including users from North America, as
> > we
> > have seen them ask questions in slack channel about Dolphin Apis)
> > attempting to use Dolphin Apis without front-end, but only to find
> > themselves consistently getting into troubles.
> >
> >
> > This is a good point. If the community wants to attract more users,
> > especially those who use APIs directly without front-end,
> > we need to decrease the bar for users to use dolphin open APIs.
> >
> > In order to make Dolphin more user-friendly and competitive around the
> > world, we suggest moving DolphinScheduler Api V2 forward.
> >
> >
> > Here are the main purpose of coming issue
> >
> > - Clarifying the specification of api layer development that everyone
> > keep in mind and follow in action
> > - Performing an incremental refactoring on the whole api layer
> > - Refining api doc generation and distribution pipeline
> >
> >
> >
> > And the working process may roughly include
> >
> > - Specification of api layer development should be proposed, carefully
> > discussed, and finally aligned among project contributors, including
> > - Resource definition and relationship
> > - CRUD operation input and output
> > - Naming conventions
> > - Versioning and Lifecycle
> > - Error Code and Message
> > - The first stage of backend dev, until every core module is covered,
> > including
> > - project
> > - process definition/process instance
> > - task definition/task instance
> > - Followed by ui service refactoring
> > - The second stage of backend dev, util every module is covered
> > - Refining api doc generation and distribution pipeline, which may
> > finally be conforming with OpenApi specification instead of Swagger
> >
> >
> >
> > AFAIK, DISP-7[1] has proposed api refactoring. However, there are several
> > details not covered. From my perspective, we could have more discussions
> > before continuing the previous work. BTW, credits to Zihao for bringing
> > up
> > this issue : )
> >
> > Above all, this is just a discussion. I will give a more specific
> > proposal
> > with a linked GitHub issue once the discussion closed.
> >
> >
> > IMHO, we could also have a PoC example by refactoring
> `ProjectController`.
> >
> > Thanks.
> >
> > [1] https://github.com/apache/dolphinscheduler/issues/10257
> >
> > Best Regards,
> >
> > Yifan Sun
>
>
>
> --
> Best Wish
> —Jay Chung
>