Hi, Thanks for all the suggestions and feedback. I have started a vote for it.
Best Regards, Fei Wang On 2024/07/02 10:17:39 Ethan Feng wrote: > Hi feiwang, > > Thanks for this proposal. I agree with the versioned REST APIs. > > Thanks, > Ethan Feng > > > Ethan Feng <ethanf...@apache.org> 于2024年7月2日周二 17:58写道： > > > > Fei Wang <feiw...@apache.org> 于2024年7月2日周二 13:04写道： > > > > > > > > Hi Keyong, > > > > > > Thanks very much for your suggestions. > > > > > > I have renamed the docs to 'CIP-9 Celeborn RESTful API Refine' and will > > > start a vote thread later. > > > > > > Thank you very much. > > > > > > Regards, > > > Fei Wang > > > > > > On 2024/07/02 04:17:34 Keyong Zhou wrote: > > > > Hi Fei, > > > > > > > > Sorry for the late reply, I reviewed the design doc and it looks good > > > > to me > > > > :) > > > > > > > > In the doc you mentioned CIP-7 Celeborn CLI[1] that relies on the rest > > > > API, > > > > since your design > > > > will reserve the current API, I think there will be no conflicts. > > > > > > > > I suggest to create a CIP for this proposal and starts a vote on it, > > > > like[2][3]. > > > > > > > > Regards, > > > > Keyong Zhou > > > > > > > > [1] > > > > https://cwiki.apache.org/confluence/display/CELEBORN/CIP-7+Celeborn+CLI > > > > [2] https://lists.apache.org/thread/xjh8z2kszq0kwj5bdz2bh3b1sotv593p > > > > [3] https://lists.apache.org/thread/bx58h25poypq0znolkb8vlhop4bw1x81 > > > > > > > > Fei Wang <feiw...@apache.org> 于2024年7月2日周二 04:53写道： > > > > > > > > > Hi celeborn community, > > > > > I hope this message finds you well. > > > > > > > > > > I would like to extend my gratitude to those who have taken the time > > > > > to > > > > > review and discuss for this proposal. Your insights and feedback are > > > > > invaluable to the progression of this project. > > > > > > > > > > As we have not received further discussions for some time, I believe > > > > > it is > > > > > appropriate to move forward with the next step in the process. > > > > > > > > > > Best Regards, > > > > > Fei Wang > > > > > > > > > > On 2024/06/25 19:18:27 Fei Wang wrote: > > > > > > Hi, > > > > > > > > > > > > Thanks Nicholas for the comments. > > > > > > > > > > > > > 1. Could you summary all /api/v1 interfaces in Public Interfaces > > > > > section? Meanwhile, could you also the definition of the parameter and > > > > > return type class like the fields of POJO? > > > > > > > > > > > > I have updated the docs and complete the parameters and response > > > > > > POJO. > > > > > > > > > > > > > 2. Could some interfaces merged into one interface like > > > > > /${version}/workers/lost, /${version}/workers/excluded and > > > > > /${version}/workers/shutdown? Should the refined REST API be mapping > > > > > to > > > > > origin interface one by one? > > > > > > > > > > > > Thanks we can merge these apis into `/${version}/workers`. The > > > > > > response > > > > > POJO. > > > > > > Name Type > > > > > > workers List[WorkerData] > > > > > > lostWorkers List[WorkerData] > > > > > > excludedWorkers List[WorkerData] > > > > > > shutdownWorkers List[WorkerData] > > > > > > decommissionWorkers List[WorkerData] > > > > > > > > > > > > And I will mapping the the api one by one. > > > > > > > > > > > > > > > > > > > 3. Could this migration plan describe more detail? For example, > > > > > > > the > > > > > origin interfaces returns string, but the refined REST API returns the > > > > > POJO? How does the user migrate the REST API? > > > > > > > > > > > > The migration of a REST API primarily involves mapping the old API > > > > > > to > > > > > the new API. Previously, the old API returned a string, whereas the > > > > > new API > > > > > returns a POJO (Plain Old Java Object) that includes all the fields > > > > > relevant to the content of the previous string response. Therefore, > > > > > the > > > > > content of the new API's response is essentially consistent with the > > > > > previous response results. > > > > > > In the migration documentation, I will detail the API mappings as > > > > > > well > > > > > as the fields in the new response. > > > > > > > > > > > > > > > > > > > 4. Some interfaces like /${version}/exit do not mentation the HTTP > > > > > method? Could you check all the HTTP method of refined REST API? > > > > > Meanwhile, > > > > > is there any standard or pattern of the naming for path? For example, > > > > > /${version}/workers/events not only list the event info for Get > > > > > method, but > > > > > also supports sending event for POST method without operation name in > > > > > path. > > > > > > > > > > > > Thanks for the reminder, I have added the method for params for all > > > > > > the > > > > > APIs. > > > > > > > > > > > > Using different HTTP methods to correspond to different actions on > > > > > > the > > > > > same API endpoint is a common practice in RESTful design. This > > > > > approach is > > > > > in line with the principles of REST, where the resource path remains > > > > > consistent while the HTTP method indicates the intended operation. > > > > > And I > > > > > have observed a similar design pattern in Apache Kyuubi Project. > > > > > > > > > > > > > > > > > > > > > > > > > 5. /${version}/conf/dynamic uses three parameters without any POJO > > > > > parameter type class, but /${version}/workers/events uses > > > > > SendWorkerEventRequest as parameter type. Could this parameter type be > > > > > unified to POJO? > > > > > > > > > > > > The api `/${version}/conf/dynamic` method is GET, request parameters > > > > > should be fine. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Fei Wang > > > > > > > > > > > > On 2024/06/25 17:22:51 Nicholas wrote: > > > > > > > Hi turboFei, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for driving the proposal of RESTful API Refine. I have some > > > > > questions about this proposal: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. Could you summary all /api/v1 interfaces in Public Interfaces > > > > > section? Meanwhile, could you also the definition of the parameter and > > > > > return type class like the fields of POJO? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Could some interfaces merged into one interface like > > > > > /${version}/workers/lost, /${version}/workers/excluded and > > > > > /${version}/workers/shutdown? Should the refined REST API be mapping > > > > > to > > > > > origin interface one by one? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3. Could this migration plan describe more detail? For example, > > > > > > > the > > > > > origin interfaces returns string, but the refined REST API returns the > > > > > POJO? How does the user migrate the REST API? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4. Some interfaces like /${version}/exit do not mentation the HTTP > > > > > method? Could you check all the HTTP method of refined REST API? > > > > > Meanwhile, > > > > > is there any standard or pattern of the naming for path? For example, > > > > > /${version}/workers/events not only list the event info for Get > > > > > method, but > > > > > also supports sending event for POST method without operation name in > > > > > path. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5. /${version}/conf/dynamic uses three parameters without any POJO > > > > > parameter type class, but /${version}/workers/events uses > > > > > SendWorkerEventRequest as parameter type. Could this parameter type be > > > > > unified to POJO? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Nicholas Jiang > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 2024-06-26 00:35:11, "Fei Wang" <feiw...@apache.org> wrote: > > > > > > > >Hi all, > > > > > > > > > > > > > > > >I have written up a proposal about refining the current > > > > > > > >Master/Worker > > > > > > > >RESTful API. You can find the proposal > > > > > > > > > > > > > https://docs.google.com/document/d/1LV2vV-w3XtlbJj2Vi4J77mt4IYCr40-8A_JncZLsHqs/edit?usp=sharing > > > > > > > >< > > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1LV2vV-w3XtlbJj2Vi4J77mt4IYCr40-8A_JncZLsHqs%2Fedit%3Fusp%3Dsharing&data=05%7C02%7Cfwang12%40ebay.com%7C71f1561af7134f08cb1808dc94eda6d9%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C638548995634818085%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1gfkqj0ocuhnKb7c4%2FB0qvJu%2Fc5U1KDi6XS4UM64m%2B8%3D&reserved=0 > > > > > > > > > > > > > > here. > > > > > > > > > > > > > > > >Please let me know if you have any comments or questions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >TLDR by refining the RESTful API, it makes integration with > > > > > > > >operations > > > > > > > >tools and Celeborn easy. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >FYI, I was not able to access the cwiki page to put this proposal > > > > > there, > > > > > > > >hope it is okay to just share as a google doc here for now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-- > > > > > > > > > > > > > > > >Fei Wang > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Celeborn RESTful API Refine Proposal > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1LV2vV-w3XtlbJj2Vi4J77mt4IYCr40-8A_JncZLsHqs/edit?usp=sharing > > > > > > > >< > > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1LV2vV-w3XtlbJj2Vi4J77mt4IYCr40-8A_JncZLsHqs%2Fedit%3Fusp%3Dsharing&data=05%7C02%7Cfwang12%40ebay.com%7C71f1561af7134f08cb1808dc94eda6d9%7C46326bff992841a0baca17c16c94ea99%7C0%7C0%7C638548995634832996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=eQA75vkDkYn2LRZxXygkNsAEbiwniT0mluZAog5JM7Q%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
