You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Aleksandr Pakhomov <ap...@gmail.com> on 2022/05/11 08:17:20 UTC
[DISCUSSION] IEP-87: Open API support for REST
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
Re: [DISCUSSION] IEP-87: Open API support for REST
Posted by Aleksandr Pakhomov <ap...@gmail.com>.
Yes, micronaut injection is going to be used but
only for controllers. The border is MicronautFactory
(see RestComponent constructor in the example).
This factory declares beans that are needed for
controllers. Each module declares its own factory.
List of factories are put to RestComponent
manually and then they are set to the context
as singletons.
> On 19 May 2022, at 10:12, Roman Puchkovskiy <ro...@gmail.com> wrote:
>
> 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
Re: [DISCUSSION] IEP-87: Open API support for REST
Posted by Aleksandr Pakhomov <ap...@gmail.com>.
Hi Roman,
Thanks for the note. I’ve updated ‘Versioning’ paragraph
with the example.
> On 19 May 2022, at 10:12, Roman Puchkovskiy <ro...@gmail.com> wrote:
>
> 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?
Re: [DISCUSSION] IEP-87: Open API support for REST
Posted by Aleksandr Pakhomov <ap...@gmail.com>.
Agreed. Thank you for comments, Roman.
> On 19 May 2022, at 10:17, Roman Puchkovskiy <ro...@gmail.com> wrote:
>
> 3. In the table in the API section, there is this phrase: 'Update node
> configuration with a given body.'. I suggest replacing 'Update' with
> 'Patch' because 'update' could mean a full replacement, and 'patch'
> makes it more specific. Same relates to 'Update cluster configuration
> with a given body.'.
Re: [DISCUSSION] IEP-87: Open API support for REST
Posted by Roman Puchkovskiy <ro...@gmail.com>.
Oops, sent it too early :) I'll proceed.
... As a side note, as far as I know, there were some discussions
about using automatic dependency injection in Ignite 3 (as the whole
system), but no decision was made.
3. In the table in the API section, there is this phrase: 'Update node
configuration with a given body.'. I suggest replacing 'Update' with
'Patch' because 'update' could mean a full replacement, and 'patch'
makes it more specific. Same relates to 'Update cluster configuration
with a given body.'.
чт, 19 мая 2022 г. в 11:12, Roman Puchkovskiy <ro...@gmail.com>:
>
> 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 <ap...@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 <ap...@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
> >
Re: [DISCUSSION] IEP-87: Open API support for REST
Posted by Roman Puchkovskiy <ro...@gmail.com>.
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 <ap...@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 <ap...@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
>
Re: [DISCUSSION] IEP-87: Open API support for REST
Posted by Aleksandr Pakhomov <ap...@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 <ap...@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
Re: [DISCUSSION] IEP-87: Open API support for REST
Posted by Andrey Gura <ag...@apache.org>.
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 <ap...@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