[
https://issues.apache.org/jira/browse/SLING-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13852955#comment-13852955
]
Lars Trieloff commented on SLING-3292:
--------------------------------------
It looks like buffering is a common approach, for instance SendGrid buffers for
1 second or until the buffer reaches a size of 1 MB:
http://sendgrid.com/docs/API_Reference/Webhooks/event.html
I would prefer Sling Resource Events, as most of Sling's API operates on this
abstraction, but to my knowledge JCR is the most common resource provider
supporting observation.
> 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)
