-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Geofencing - Adding SUBSCRIPTION_DELETED
as a Termination Reason
#141
Comments
This may have sense, but it is something that would apply to subscriptions for all APIs, wdyt @PedroDiez ? |
If we assume deletion of subscription is a synchronous operation, successful response to DELETE operation is sufficient. To be flexible, we can support both. But then we should define 2 different success responses to DEL so that the client would now if deletion is completed or they should wait for a notification. Having said that, we could also make creation of subscription asynchronous (HTTP 201 created followed by a notification later). |
Hello @alpaycetin74 But we cannot assume technical correlation between the system listening to the event channel (the target of the notificationUrl) and the system performing the DELETE (OK this is the problem of the consumer). Does it make sense? |
hello @bigludo7 , |
Yes, think makes sense for APIs that have explicit subscriptions model (i.e. Resource-based). Think this is something to be indidated/align in commonalities |
Hello To be aligned with this API we should use |
I have seen @akoshunyadi 's comment saying "DELETE_REQUESTED" sounds like it is not final, and still some final event is to come. I'd prefer SUBSCRIPTION_DELETED as well. |
Hello @alpaycetin74 ....yes agreed with you of the interpretation but probably the idea is to have consistence with QoD API. (https://github.com/camaraproject/QualityOnDemand/blob/v0.10.0/code/API_definitions/qod-api.yaml#L918). Conclusion: make sense to set this at commonalities level to have a de facto alignement. |
The discussion about subscription lifecycle management in commonalities: camaraproject/Commonalities#153 |
SUBSCRIPTION_DELETED
as a Termination Reason
Problem description
Feedback from implementation.
For the
terminationReason
we have following value:NETWORK_TERMINATED
- API server stopped sending notificationSUBSCRIPTION_EXPIRED
- Subscription expire time (required by the requester) has been reached.We did not have a specific value when the termination was triggered from a DELETE operation.
We can assume that because the consume side perform the DELETE no need for notification but for sake of consistency send an event seems to be a good option.
Possible evolution
Add value
SUBSCRIPTION_DELETED
in theterminationReason
arrayAlternative solution
Additional context
The text was updated successfully, but these errors were encountered: