Skip to content
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

GET api/v1/notifications is not idempotent #7268

Open
manuelwedler opened this issue Aug 3, 2021 · 2 comments
Open

GET api/v1/notifications is not idempotent #7268

manuelwedler opened this issue Aug 3, 2021 · 2 comments
Labels
Component / API Issues that relate the the APIs Raiden provides. Type / Bug

Comments

@manuelwedler
Copy link
Contributor

Problem Definition

A GET api/v1/notifications request returns only new notifications since the last request to the endpoint. The API deletes all notifications when this endpoint is called.
This is a clear misuse of the HTTP GET method, as it should always be idempotent and should never change resources in the raiden client. It would be better if the endpoint would return all notifications that are currently relevant. Notifications should only be removed if they are not relevant anymore, for example after the user deposits to the UDC the low RDN notification should be removed.

System Description

raiden v2.0.0

@manuelwedler manuelwedler added Component / API Issues that relate the the APIs Raiden provides. Type / Bug labels Aug 3, 2021
@karlb
Copy link
Contributor

karlb commented Aug 5, 2021

We could change the request to GET api/v1/notifications?since=NOTIFICATION_ID (and limit maximum amount of returned messages).

@ulope
Copy link
Collaborator

ulope commented Aug 9, 2021

That would only solve the idempotence issue, not how notifications get removed.

I agree with @manuelwedler that their lifecycle should be managed from where they were created.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component / API Issues that relate the the APIs Raiden provides. Type / Bug
Projects
None yet
Development

No branches or pull requests

3 participants