Sign up or Log in
4.15 Improving Reliability with Idempotent Create While the common practice is to use HTTP POST to create new resources in Web APIs, that is not the most reliable. In fact, when it comes to machine-to- machine interactions (e.g. no humans in the loop), using HTTP POST can be problematic because of the possibility of the “Lost Response” problem. What is needed is a solution to creating resources that is repeatable and reliable, even when the network connections themselves may be faulty. Problem When using HTTP POST to create new resources, it is possible to experience the “List Response” problem. For example, an API client sends a POST with a boy that transfers $500 from account A to account B and that API client never receivesanHTTPresponse.No200 OK,no400 Bad Request,no500 Server Error — nothing. Now what is the client to do? Did the request ever make it to the server? Was there a server-side error that rejected the request? What if the request made it to theserverandwascompleted,butthe200 OKresponsegotdroppedonthe network? In that last case, repeating the request might result in executing the transfer twice. How can we avoid the bad effects of the Lost Response problem when writing data to the service?4.15 Improving Reliability with Idempotent Create While the common practice is to use HTTP POST to create new resources in Web APIs, that is not the most reliable. In fact, when it comes to machine-to- machine interactions (e.g. no humans in the loop), using HTTP POST can be problematic because of the possibility of the “Lost Response” problem. What is needed is a solution to creating resources that is repeatable and reliable, even when the network connections themselves may be faulty. Problem When using HTTP POST to create new resources, it is possible to experience the “List Response” problem. For example, an API client sends a POST with a boy that transfers $500 from account A to account B and that API client never receivesanHTTPresponse.No200 OK,no400 Bad Request,no500 Server Error — nothing. Now what is the client to do? Did the request ever make it to the server? Was there a server-side error that rejected the request? What if the request made it to theserverandwascompleted,butthe200 OKresponsegotdroppedonthe network? In that last case, repeating the request might result in executing the transfer twice. How can we avoid the bad effects of the Lost Response problem when writing data to the service?
—

Restful Web API Patterns and Practices Cookbook
by Mike Amundsen

aha hah
Source
Actions
Flag
ShareFind originalDownload
1 Connection
Connect →
hypermedia web
42 blocks
by aha hah