General Question: API structure of wicked portal application about wicked.haufe.io

[DonMartin76]

Hi Aaron, yes, that's about it. See the following documents:

• https://github.com/Haufe-Lexware/wicked.haufe.io/blob/master/doc/deployment-architecture.md for the general structure of the system (including default ports).

The following Swagger files for the APIs among the components:

• portal-api APIs: https://github.com/Haufe-Lexware/wicked.portal-api/tree/master/swagger
• portal-kong-adapter API (for 0.10.0): https://github.com/Haufe-Lexware/wicked.portal-kong-adapter/blob/oauth2_implicit/resources/swagger/oauth2-swagger.yml
• The documentation of the portal's "API" (it's not an actual API, as it's the web site): https://github.com/Haufe-Lexware/wicked.portal/blob/master/swagger/portal-swagger.yaml

Please note that I will possibly retract the latter API (of the web site) in favor of exposing the internal API via OAuth2 instead. Otherwise I would get into trouble as soon as I introduce CSRF protection.

In the portal-api Swagger documentation you will also see the API definition a webhook listener has to implement; chatbot and mailer do not have their own swagger file, they just implement the listener one. As does the kong adapter; the kong adapter will get some additional things for helping doing OAuth2 flows in 0.10.0.

Hope that helps, Martin

[DonMartin76]

Are there any open issues with this, or can I close it?

[TESAARON]

Hi Martin,

Thanks for the info on this. We are looking to customize part of the portal for our own specific product needs so good to know how the code itself is broken down.

Feel free to close the issue.

Regards,
Aaron

[DonMartin76]

What would really interest me: Which parts of the portal do not meet your requirements? If you move away from the "main branch", you will not get automatic feature upgrades.

[TESAARON]

Hi Martin,

Yes we figured that we would lose the benefit of upgrades all right if we branched off. The api portal itself has all that we need from an API dev and consume perspective. However, we are looking to build a layer on top of the APIs for end user experience applications i.e. an Excel workbook that consumes numerous wicked APIs. We are approaching this from a 'data product marketplace' rather than solely an API marketplace.

This may be slightly removed from your current course with Wicked, hence why we are looking at developing some custom changes specific to our line of work. Does this make sense?

[DonMartin76]

Sure makes sense. As long as you are aware of the consequences if you would need to branch. Best regards, Martin. (Closing now)