[
https://issues.apache.org/jira/browse/SLING-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved SLING-3292.
-------------------------------------
Resolution: Won't Fix
> 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
(v8.20.10#820010)
