Lars Trieloff created SLING-3292:
------------------------------------
Summary: Web Hooks for Resource Observation
Key: SLING-3292
URL: https://issues.apache.org/jira/browse/SLING-3292
Project: Sling
Issue Type: New Feature
Components: Extensions
Reporter: Lars Trieloff
Priority: Minor
I have an application that is storing resources for multiple other web
applications and makes them available through the Sling REST API. Each of the
consuming web applications has implemented their own caching and polling
strategy for the resources made available by my Sling web application.
In order to reduce latency when resources get updated in my Sling web
application, and to reduce the need for polling resources on the side of my
consuming web application, I would like to support Web Hooks
(https://webhooks.pbworks.com/w/page/13385124/FrontPage - a pattern also
supported by applications such as GitHub
https://help.github.com/articles/post-receive-hooks or Evernote
http://dev.evernote.com/doc/articles/polling_notification.php), so that client
applications can register callbacks when one of the resources in my web
application changes.
The events to be observed should be:
* resource added
* resource moved
* resource deleted
* resource updated
An observing application should be able to specify:
* a pattern of resource paths it is interested in
* a collection of resource types it is interested in
* a collection of events it is interested in
* a callback URL that should receive POST requests when a change matching the
pattern above has been made
The subsequent POST request should contain following information
* timestamp of the change
* URL of the changed resource
* event type of the change
* user initiating the change
Furthermore, observing applications should be able to
* create a new listener using a POST request
* GET the list of listeners already registered
* POST to update or delete an existing listener
h5. Error Handling
In case the registered callback URL is not available, Sling should retry the
notification POST request, with increasing time between retries.
After a maximum number of retries, the listener should be blacklisted, so that
no further retries are being made
h5. Configuration
* maximum number of retries
* enforce HTTPS (for production use)
* authentication for outgoing requests
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
