Affects Version/s: None
Fix Version/s: None
How about exposing event subscriptions api endpoint??
I would like to propose :
- endpoint path => /v2/event_subscriptions
- supported methods =>
- POST with ?callback_url<br/> returns whether registration was succeeded or not. <br/>And, this api call will be also notified subscribers (including callee).
- DELETE with ?callback_url<br/> returns whether un-registration was succeeded or not. <br/> And, this api call will be also notified subscribers (excluding callee).
- GET <br/> returns list of subscribers. <br/> And, this api call will NOT be notified. ( I know that Event-Bus says that "Marathon has an internal event bus that captures all API requests and scaling events.")
Design Issue: Api endpoints should return some results to clients. However, Marathon currently utilizes Guava's event bus for event notifications. And, as you guys might notice, Guava's eventBus.post is totally one-way, which means it's difficult to return values. I suppose that this is one of reason which Marathon doesn't expose event subscription api. But I believe that event subscription api would be helpful for Marathon.
So, I think event bus doesn't fit if we would support event subscription endpoints. If we supported this, we could use event notification service like MarathonSchedulerService instead of Guava's event bus.
I'm appreciated if I would hear what Marathon contributors think about this.
Actually, I've started implementing this on my own repo: everpeace/marathon/add-subscription-endpoint