I wonder if a pattern with a URL to a resource is optimal as there will be a lot of versions of a particular resource that are not needed. I mean, after an event consumption all versions of a resource, except the latest one, are redundant. I wonder if adding some retention mechanism would do the job. Anyway, a really good article :) Cheers!

I find other usages for Notification Style Events.
I assume the following:
- Events of given type go on some sort of topic, that has many subscribers
- Subscriber can get the events in different order than they were produced
- Subscriber can get down for some period of time and when he comes back up, he should not mess anything up because he didn't handle messages immediately

I've got something like that:
- Important Object Is Changed (which happens usually not so often) - it might be changed, it might be deleted.
- 3 different subscribers have process that takes most recent state of Important Object (through querying db), and handle them in their own transactions, creating their own version of Important Object with some calculations that are subscriber specific.
- If something get messed up I can always resend Important Object Is Changed and this will always correct output state of Subscribers.

Since all that happens is state manipulation of Important Object and most recent data that subscriber owns, I'm making the process indepotent. I can save information within subscriber code about which version of Important Object has been last handled just to have more auditability.

If I were to be more specific with event and pass new state of Important Object, and messages were to be handled not in order, then it would be a new problem to solve, with not much value added.