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