Hi Aleksandr. Thank you for your effort, it looks interesting. I have a few comments/questions on some little details.
1. About the paragraph named 'Versioning'. Could you please elaborate what is the difference between 'API version' and 'specification version'? Both might have 'breaking changes', what does it mean in each of the cases? 2. If I'm not mistaken, at runtime, Micronaut maintains an application context containing beans, these beans can be injected into other beans and components (like controllers). In your example code, RestComponent receives a RestConfiguration instance via constructor. Is the RestConfiguration instance injected automatically by the Micronaut IoC container? Is the IoC injection going to be used at all? If yes, given that currently Ignite 3 uses no such automagic injection, then what are the planned/supposed bounds of the area which would use automatic injection and how will we build the 'border' between auto-injecting and non-auto-injecting code? (For instance, how our RestConfiguration will be registered with the Micronaut context?) As a sidenote чт, 12 мая 2022 г. в 23:22, Aleksandr Pakhomov <apk...@gmail.com>: > > Hi, Andrey. > > Thank you for your comments. > > I've put the main value to the description and added "artifact management" > part [1]. > Yes, you are right. I've adjusted the IEP. > 3, 4, 5. Done. > > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Artifactmanagement > > <https://cwiki.apache.org/confluence/display/IGNITE/IEP-87:+Open+API+support+for+REST#IEP87:OpenAPIsupportforREST-Artifactmanagement> > > > > On 11 May 2022, at 16:46, Andrey Gura <ag...@apache.org> wrote: > > > > Hi, > > > > I took a look at the proposal and have some questions and comments. > > > > 1. It is not clear what the main value of this proposal is. The > > current implementation of REST is code-first. API specification could > > be written manually. It seems that the main value is the possibility > > to generate an API specification from code. If so, then it would be > > great to point it out strongly. Otherwise, this proposal looks like an > > attempt to replace one implementation by another one (may be more > > popular) but with additional 3rd party dependencies. Also, it would be > > great to propose a process of artefact management (what should we do > > and when) in relation to specification (Where it should be published? > > Should it be placed in a source code repository or not? Should we do > > some version management?) > > > > 2. The "Modular architecture support" part says: "Ignite modules can > > provide endpoints that will be included into the netty server by > > RestComponent **at the build time**". If I understood correctly, we > > talk only about endpoints here, but registration/deregistration of > > handlers for known endpoints could be done at runtime. Am I right? > > > > 3. The "API" part refers to the meta storage nodes and CMG nodes. > > Could you please refer to a document which introduces these concepts? > > > > 4. Also it would be great to state that the proposed API actually is > > the current API which exists in Apache Ignite. > > > > 5. The task about developer documentation should be added to the > > issues list. The documentation is a readme.md file which will help an > > Ignite developer to understand how to add a new endpoint, how to > > generate API specification, etc. > > > > On Wed, May 11, 2022 at 11:17 AM Aleksandr Pakhomov <apk...@gmail.com> > > wrote: > >> > >> Hello, Igniters. > >> > >> I’d like to start a discussion about Open API support for REST [1]. The > >> main purpose of this improvement is to add the support of Open API > >> specification by generating it from the source code. > >> > >> [1] > >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-87%3A+Open+API+support+for+REST >
