If you think you need to issue an HTTP call to "publish" an event, you're misapplying messaging thinking to REST and actually send a command. *Expose* the events of a system via a feed and let client's subscribe to them. Publishing is providing the feed. #APICon

Using HTTP to poll for changes in an event feed is a terribly inefficient way to implement eventing.

There’s no magic. Pull with request/response is worse than push in terms of e2e latency, bottlenecks subscribers on the feed endpoint, and prevents intermediaries like proxies and load balancers from shaping the delivery path. It’s taking less advantage of the REST architecture

All I said was that the idea of having to send a POST somewhere to publish a message is just wrong *if* you want to implement events using REST. *Whether* that’s a good idea depends on context and is not something properly discussable in 280 chars.

And I disagree with the premise because distributed systems has distributed resources and relationships between those resources. A “subscription” may quite well be a relationship asking one resource to propagate state changes to another. POST is a perfectly legitimate option.

I agree and disagree with all of you to varying degrees :) Publishing events via a feed is often the best solution if you prioritize lightweight, decoupled communication over efficiency.