How would an API layer enable guaranteed/assured delivery model. Is the right place to put this solution in?

Not applicable
 
1 3 1,182
3 REPLIES 3

Not applicable

I am tempted to say in agreement with my colleague @David Allen that this lies outside the API management layer, to be delegated over to a solution designed and built for this specific capability. I will be keen to see how others think of this.

Not applicable

Assuming I’m understanding this question correctly, I would agree with @David Allen that no one should be using an HTTP-based architecture for guaranteed delivery. That said, there are patterns that can be used when such a thing is needed, where the client makes calls back to acknowledge delivery. We see this sometimes in things like push notification APIs where there is a way to obtain read receipts.

Not applicable

@ed@apigee.com @David Allen May I might geek out the conversation a bit more. The future of internet is that backends should be able to receive multiple requests and still, when required, behave as if one and only one request came. This pattern (idempotency), and allows the caller to call as many times as needed, and achieve near fault-tolerant/guaranteed delivery at a fraction of the cost. All the two phase commits, distributed syncing etc. is no way to build internet style architectures.