API Reliability

[mingyc]

Current spec proposal whatwg/fetch#1647 does not include anything about reliability.

The question about "How reliable fetchLater should be" has been brought up again during Chromium implementation. Quoted from the discussion:

My feeling is that the proposed fetchLater API is not suitable for mission critical applications.
For example, there is no way to detect network error. So if the network is not available (it is
common on mobile networks), the requested data will just be lost. And there is no way to detect 
such failure.

Considering this fetchLater API is not for mission critical applications, I think it is reasonable
to accept the risk of data lost if the renderer crashes while [updating a pending request]
(https://github.com/WICG/pending-beacon/blob/f4f4b31/docs/fetch-later-api.md#update-a-pending-request).

I don’t know what level of robustness web developers want. But if we want to implement a more
robust API, I think the design of the API will be similar to [Background Fetch API]
(https://wicg.github.io/background-fetch/). (There seems no way to update requests in the 
Background Fetch API though.)

Note that retry & recovery from storage are also in the following issues:

• Retry: Consider to support retry mechanism #40
• Crash Recovery: Crash recovery #34