[jira] [Resolved] (SLING-3292) Web Hooks for Resource Observation

["Carsten Ziegeler (Jira)" <ji...@apache.org>]

     [ 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)