Accommodate asynchronous pattern

[bigludo7]

Problem description
This topic is mentioned here #10 but probably deserves it owns issue.
Seems that for UCs we can provide asynchronous answer that will allow us more flexibility to handle the request.
If we want to offer this capability we need slight changes.

Possible evolution

• add 202 as possible answer
• add callbackurl & token in the request. By valued them the consumer expect to get an asynchronous answer and this answer will be posted to this callbackUrl

Alternative solution

• add 202 as possible answer
• add a requestId in the POST response & provide GET operation but this change a bit more the API

Additional context

[sachinvodafone]

I believe, the first approach with the callback URL and token is more appropriate for our current API scenario. Providing the callback URL in the initial response simplifies the process for the client, eliminating the need for additional requests (first to get subscription ID and then CallbackURL) or managing subscription IDs. Additionally, since the client is only interested in receiving the processed data once, there's no need for a subscription model or ongoing updates.

[jgarciahospital]

Agreed that first option allows a better and more refine approach, also enabling sync use case in case callback is not included in the request, but on the other side provides a higher complexity for the developer to enable such callback endpoint.

Based on meeting discussions, #21 is including callback proposal as reference, with some modifications to be implemented, but discussion will remain opened at least until next meeting.

[sachinvodafone]

Agreed, we can go with first option to have callback URL.

[bigludo7]

Works for me.
Note: As we are changing the subscription model I expect some name change for the attributes. It will not change the fonction of the callback but the attributes instead of webhook should be sink. Perhaps let's wait this update before to change the yaml.

[jgarciahospital]

With these two validations, I'd suggest to merge this PR to follow discussion on additional specification topics.

[jgarciahospital]

@sachinvodafone can we merge?