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 > > > > > > > >
