You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great to get notified of incoming payments or other important events.
Motivation
Setting up subscriptions is currently not possible which is unfortunate.
It would be great to get notified by incoming payments.
Ideally this would be done over websockets, as they support subscriptions.
I know that this is not possible in REST API's but I thought of the following scheme:
Specification
User could set up subscriptions by calling a rest endpoint setup with the filters that they want to set up.
The call returns a unique id. The user can then call the /all/id endpoint or something similar to query everything that matches their filter.
They can also call /new/id to get all the new transactions/events that matched the filter since the last call.
Doing so would greatly improve the UX of the REST API.
Backwards Compatibility
Introducing two new endpoints setup and /all/id would not impact the REST API for any other methods. Internally all new events would need to be checked against a queue of filters which could probably impact performance a bit, but I think that's worth it for the support of subscriptions.
The text was updated successfully, but these errors were encountered:
Abstract
It would be great to get notified of incoming payments or other important events.
Motivation
Setting up subscriptions is currently not possible which is unfortunate.
It would be great to get notified by incoming payments.
Ideally this would be done over websockets, as they support subscriptions.
I know that this is not possible in REST API's but I thought of the following scheme:
Specification
User could set up subscriptions by calling a rest endpoint
setup
with the filters that they want to set up.The call returns a unique id. The user can then call the
/all/id
endpoint or something similar to query everything that matches their filter.They can also call
/new/id
to get all the new transactions/events that matched the filter since the last call.Doing so would greatly improve the UX of the REST API.
Backwards Compatibility
Introducing two new endpoints
setup
and/all/id
would not impact the REST API for any other methods. Internally all new events would need to be checked against a queue of filters which could probably impact performance a bit, but I think that's worth it for the support of subscriptions.The text was updated successfully, but these errors were encountered: