docs: generate OpenApi spec

[tuncaytunc-zf]

Generate OpenApi specification to document all our APIs which are exposed in tractusx-edc.

[florianrusch-zf]

Please be so kind and take a look at our pr etiquette. Your PR title and description do not match our guidelines 🙂

[florianrusch-zf]

@tuncaytunc-zf could you please briefly explain in the description why this becomes necessary and what is the purpose of it? So that when we look at this PR again in a year's time, we will understand directly why we did this.

[stephanbcbauer]

Hey @tuncaytunc-zf

In general, I am fine with the PR. I am just wondering if you could add a little more description to the openAPI. In the End, it will be shown in the developer hub.

And I think there are more examples needed? For example, the result object, error codes aso?

For example, like the openAPI for managmenet-api which ends up in tractusx documentation

THX

[tuncaytunc-zf]

Hey @tuncaytunc-zf

In general, I am fine with the PR. I am just wondering if you could add a little more description to the openAPI. In the End, it will be shown in the developer hub.

And I think there are more examples needed? For example, the result object, error codes aso?

For example, like the openAPI for managmenet-api which ends up in tractusx documentation

THX

Hi @stephanbcbauer this PR was just to implement the API generation out of the existing APIs, if the APIs need to be enriched with additional information we could do it with a separate PR.

[stephanbcbauer]

LGTM

[wolf4ood]

LGTM

[florianrusch-zf]

I'm not a fan of first implementing something and then having the documentation in another PR - that's mostly the first step to forget about the documentation task 😕

Also while reviewing #138 I expected, that your openapi would be also considered there. Is this already the case? \cc @stephanbcbauer @bcronin90

So I don't want to say I'm against what you have done. I just want to ensure, that it's not simply implemented and then everyone will forget about it. Hope you understand my point of view!

[stephanbcbauer]

I'm not a fan of first implementing something and then having the documentation in another PR - that's mostly the first step to forget about the documentation task 😕

Also while reviewing #138 I expected, that your openapi would be also considered there. Is this already the case? \cc @stephanbcbauer @bcronin90

So I'm not wanted to say I'm against what you have done. I just want to ensure, that it's not simply implemented and then everyone will forget about it. Hope you understand my point of view!

Hey @florianrusch-zf . No its not. Thats what i meant with more description. If we want to publish it, wen defently need more context

[stephanbcbauer]

I'm not a fan of first implementing something and then having the documentation in another PR - that's mostly the first step to forget about the documentation task 😕
Also while reviewing #138 I expected, that your openapi would be also considered there. Is this already the case? \cc @stephanbcbauer @bcronin90
So I'm not wanted to say I'm against what you have done. I just want to ensure, that it's not simply implemented and then everyone will forget about it. Hope you understand my point of view!

Hey @florianrusch-zf . No its not. Thats what i meant with more description. If we want to publish it, wen defently need more context

@tuncaytunc-zf can we also add more information within this ticket?

[tuncaytunc-zf]

Hi @florianrusch-zf I didn't implement either any API nor wrote any documentation. I have just configured the build to be able automatically produce an api spec for the APIs that already exists, as described in A1IDSC-421. The most of configuring the build was already done by Paul while migrating it to Gradle. Additionally to that I just added a name Tag to the api to see at least the name of the api.
Refactoring/enriching the APIs to have more information in api spec was not part of the ticket I had to implement. Therefore I have suggested to make the refactoring with another PR to not mix it up. Of course we could first refactor the API and then expose it but these are two separate things for me :-)

[bcronin90]

Also while reviewing #138 I expected, that your openapi would be also considered there. Is this already the case? \cc @stephanbcbauer @bcronin90

It's not as of yet, but it probably should be.

[tuncaytunc-zf]

As agreed with @stephanbcbauer there will be another PR/Ticket for the integration into Docusaurus.

[florianrusch-zf]

Fine for me 😉