With webhooks, consumers get to asynchronously respond to updates from a provider. If no data has changed, a provider will not send any updates.

With SCROLL, consumers are responsible for choosing when to ask a provider for updates. Without a mechanism for knowing when data has changed, consumers will be forced to be pessimistic and poll providers for new data on some cadence.

I see two issues with the proposal: (1) SCROLL will lead to an increase in unnecessary network traffic for both the consumer and provider, and (2) because a consumer cannot know when data has changed, the lag between a consumer's local model and the provider's data model will be larger when with Webhooks.

▲

lxgr 4 hours ago | parent | next [-]

Assuming you're not using the proposed streaming option, I suppose you could always send a webhook for that fact alone? In other words, an empty notification, with semantics of "something has probably changed, better poll the SCROLL if you aren't already".

	▲	Multicomp 3 hours ago \| parent [-]
		Doesn't doing that just reinvent eTags on hypertext resources from the RESTful wars and XML Web Services days 20 years ago? 1. Long Poll the cursor to pull down the latest events 2. Trigger a long-poll even if in exponential backoff because they shot you a webhook saying 'eTag changed!'

▲

inigyou 4 hours ago | parent | prev [-]

If your API is just wrapping Kafka, it can long-poll