No code generator can be perfect. You always need to modify something, so it's better not to use it. Machines cannot do better than humans, we can optimize the code, improve performance and so on. Therefore, I think that an official SDK cannot be generated by a code generator. This is a serious problem.
Zeping Bai <[email protected]>于2021年9月26日 周日上午11:21写道： > Yes, it seems that it supports protobuf generation[1] experimentally. But > I'm not sure if it can meet our needs. > > [1] https://openapi-generator.tech/docs/generators/protobuf-schema > > Chao Zhang <[email protected]> 于2021年9月26日周日 上午11:12写道： > > > Can the OpenAPI help to generate protocol buffer types? Sometimes we > > may rely on it so that data can be transmitted with the gRPC protocol. > > Best regards > > Chao Zhang > > > > https://github.com/tokers > > > > On Sun, Sep 26, 2021 at 11:07 AM ZhengSong Tu <[email protected]> > > wrote: > > > > > > if the SDK is generated by `openapi generator`, what is its form? code > or > > > jar? > > > > > > I think even if it was code, then as an SDK there would still be things > > > like reading admin-keys, hosts etc from the config file that would > still > > > need to be written. > > > *ZhengSong Tu* > > > My GitHub: https://github.com/tzssangglass > > > Apache APISIX: https://github.com/apache/apisix > > > > > > > > > Zeping Bai <[email protected]> 于2021年9月26日周日 上午9:51写道： > > > > > > > You may have misunderstood what I said about OpenAPI. In fact, we can > > > > directly generate a multilingual SDK through a definition file > > conforming > > > > to the OpenAPI specification and use the `openapi generator`[1] tool. > > > > Therefore, OpenAPI will be used as the cornerstone. > > > > > > > > [1] https://openapi-generator.tech/docs/generators > > > > > > > > 孙昊 <[email protected]> 于2021年9月25日周六 下午11:23写道： > > > > > > > > > I mean: We must not only have the SDK, but also ensure the > > consistency > > > > and > > > > > correctness of the SDK and OpenAPI, and the most important thing is > > > > > versatility. > > > > > > > > > > Sheng Wu <[email protected]> 于2021年9月25日周六 下午11:05写道： > > > > > > > > > > > > I think we should not only own the java sdk > > > > > > > > > > > > What does `should not` mean actually? > > > > > > > > > > > > Sheng Wu 吴晟 > > > > > > Twitter, wusheng1108 > > > > > > > > > > > > 孙昊 <[email protected]> 于2021年9月25日周六 下午10:32写道： > > > > > > > > > > > > > > Hi: > > > > > > > I think we should not only own the java sdk, we must also > > > > > standardize > > > > > > > it. In the future, we may also provide java sdk for spring and > > the > > > > > > starter > > > > > > > of spring boot, because more and more people are using the > > framework > > > > > > around > > > > > > > spring. Of course, SDKs in other languages cannot be forgotten, > > such > > > > as > > > > > > > JavaScript, Python, Go, etc. > > > > > > > > > > > > > > Zeping Bai <[email protected]> 于2021年9月25日周六 下午8:29写道： > > > > > > > > > > > > > > > Hi, > > > > > > > > I very much agree to provide the Admin API SDK, but I see > > that > > > > > you > > > > > > > > only mentioned the Java language. In fact, I think if we can > > > > provide > > > > > an > > > > > > > > OpenAPI (Swagger) [1] specification file, we can generate > > normal > > > > API > > > > > > > > documents and multi language SDKs with the help of OpenAPI > > > > generator > > > > > > > > tool [2]. > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > [1] OpenAPI Specification < > > https://swagger.io/resources/open-api/> > > > > > > > > [2] OpenAPITools/openapi-generator > > > > > > > > <https://github.com/OpenAPITools/openapi-generator> > > > > > > > > > > > > > > > > 孙昊 <[email protected]> 于2021年9月25日周六 下午6:45写道： > > > > > > > > > > > > > > > > > Hi: > > > > > > > > > If your team thinks my suggestion is reasonable, I am > > very > > > > > happy > > > > > > to > > > > > > > > > assist you in this matter. I have used Java as the main > > > > development > > > > > > > > > language for 10 years. > > > > > > > > > About the "mustake": > > > > > > > > > 1. When I want to use an API, I have to go to the > > official > > > > > > website of > > > > > > > > > apisix to find documentation. If we have a perfect javadoc, > > we > > > > can > > > > > > solve > > > > > > > > > this problem greatly. > > > > > > > > > 2. It may be due to carelessness, wrong parameter names > > and > > > > > wrong > > > > > > > > > types. This will cause a lot of trouble. But Java is > strongly > > > > > typed, > > > > > > and > > > > > > > > > this type of problem can be avoided. > > > > > > > > > > > > > > > > > > Zhiyuan Ju <[email protected]> 于2021年9月25日周六 下午6:37写道： > > > > > > > > > > > > > > > > > > > Good suggestion! Does anyone else also like this kind of > > SDK? > > > > If > > > > > > so, > > > > > > > > > would > > > > > > > > > > you like to take this project? > > > > > > > > > > > > > > > > > > > > BTW, may I know the details information about “mustake” > you > > > > mean? > > > > > > > > > > > > > > > > > > > > 孙昊 <[email protected]>于2021年9月25日 周六下午6:27写道： > > > > > > > > > > > > > > > > > > > > > Hello, everyone: > > > > > > > > > > > Our company now uses apisix as our api gateway, and > > our > > > > > main > > > > > > > > > > > development languages are Java and JavaScript. > > > > > > > > > > > In the process of using apisix, we often use the > > admin > > > > api > > > > > of > > > > > > > > > apisix. > > > > > > > > > > > We need to create and initiate requests repeatedly, > > which is > > > > > very > > > > > > > > > > > cumbersome, and sometimes, the parameter names, > parameter > > > > > types, > > > > > > etc. > > > > > > > > > are > > > > > > > > > > > mistaken. So, I suggest that the apisix team can > release > > an > > > > SDK > > > > > > > > toolkit > > > > > > > > > > for > > > > > > > > > > > Java, Types can be defined inside, because Java is > > strongly > > > > > > typed. > > > > > > > > > > > Good luck to everyone! > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > 来自 琚致远 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- 发自移动版 Gmail
