Added Notification management aligned with CloudEvents format

[bigludo7]

What type of PR is this?

• enhancement/feature

What this PR does / why we need it:

Aligned with CloudEvents format as defined in Commonalities here: https://github.com/camaraproject/Commonalities/pull/56

Which issue(s) this PR fixes:

Fixes #74 #57

Special notes for reviewers:

Changelog input

- Provide roaming status subscription & notification aligned with Cloudevents structure.

Additional documentation

This section can be blank.

docs

[akoshunyadi]

@bigludo7 This PR fixes also Issue #57 ?

[bigludo7]

@bigludo7 This PR fixes also Issue #57 ?

@akoshunyadi correct ! - fixed.

[sachinvodafone]

In some responses, we are having missing "status":

[sachinvodafone]

What kind of response can the client anticipate when they receive a subscription ID in a 202 response code (asynchronous process) and attempt to access /subscriptions/{subscriptionId} where process is still not completed ?

1. 202 Accepted (Still Processing):
2. 404 Not Found (Subscription ID Not Found)

[bigludo7]

What kind of response can the client anticipate when they receive a subscription ID in a 202 response code (asynchronous process) and attempt to access /subscriptions/{subscriptionId} where process is still not completed ?

1. 202 Accepted (Still Processing):
2. 404 Not Found (Subscription ID Not Found)

Good question and probably should tackled in a larger extend than this API. I will imagine 202 is a better option.

[sachinvodafone]

What kind of response can the client anticipate when they receive a subscription ID in a 202 response code (asynchronous process) and attempt to access /subscriptions/{subscriptionId} where process is still not completed ?

1. 202 Accepted (Still Processing):
2. 404 Not Found (Subscription ID Not Found)

Good question and probably should tackled in a larger extend than this API. I will imagine 202 is a better option.

So in this scenario, we must have 202 in response code against "/subscriptions/{subscriptionId}"

[sachinvodafone]

Typo mistake "0" instead of "500" error code without valid code and message in response example:

[bigludo7]

Thanks @sachinvodafone for the approval; @akoshunyadi and @fernandopradocabrillo looking also for your approval or comments. Your are not 'formal code owners but as you provided comments I'l also looking for your approval. Thanks

[fernandopradocabrillo]

What kind of response can the client anticipate when they receive a subscription ID in a 202 response code (asynchronous process) and attempt to access /subscriptions/{subscriptionId} where process is still not completed ?

1. 202 Accepted (Still Processing):
2. 404 Not Found (Subscription ID Not Found)

Good question and probably should tackled in a larger extend than this API. I will imagine 202 is a better option.

So in this scenario, we must have 202 in response code against "/subscriptions/{subscriptionId}"

I'm not really sure a 202 is the best option to return. If I create a subscription, receive a 202 and request the info before it is created, the subscription hasn't been created yet so I'd say it is better a 404.

I haven't seen a 202 in a GET, it is a bit weird. I think it adds complexity to the implementation because the response may vary if I make the call and receive a 202 and 5mins later I receive a 200 with the info, this does not happen with the POST/PUT operations since you only make the call once. And this will force the backend to have some way of tracking the process of creating the subscription to know what to return depending on the moment.

IMO I think it is more common to return a 404 and when the subscription is created, return the 200.

cc: @bigludo7 @sachinvodafone

[bigludo7]

What kind of response can the client anticipate when they receive a subscription ID in a 202 response code (asynchronous process) and attempt to access /subscriptions/{subscriptionId} where process is still not completed ?

1. 202 Accepted (Still Processing):
2. 404 Not Found (Subscription ID Not Found)

Good question and probably should tackled in a larger extend than this API. I will imagine 202 is a better option.

So in this scenario, we must have 202 in response code against "/subscriptions/{subscriptionId}"

I'm not really sure a 202 is the best option to return. If I create a subscription, receive a 202 and request the info before it is created, the subscription hasn't been created yet so I'd say it is better a 404.

I haven't seen a 202 in a GET, it is a bit weird. I think it adds complexity to the implementation because the response may vary if I make the call and receive a 202 and 5mins later I receive a 200 with the info, this does not happen with the POST/PUT operations since you only make the call once. And this will force the backend to have some way of tracking the process of creating the subscription to know what to return depending on the moment.

IMO I think it is more common to return a 404 and when the subscription is created, return the 200.

cc: @bigludo7 @sachinvodafone

OK! I guess need extra discussion for adding 202 for GET when we have potentially ASYNC creation. As this topic is larger to this API I have removed the 202 and adding this point here: https://github.com/camaraproject/Commonalities/issues/83 @sachinvodafone hope it's ok for you.