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 <[email protected]> 于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" <[email protected]> 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 > > > > > > > > > > > > >
