Other HTTP methods, such as POST, PUT, or DELETE, are typically indicative of a user action whereby confirmation that it has been communicated is the main requirement. In these situations, a cache isn't helpful; if requested a second time, the cache could stop our action from reaching the server at all. For this reason, it's uncommon to cache these requests. Moreover, if we're to build a resilient application, we need to plan for unsuccessful requests. In these situations, the server may or may not have received our request and the action may or may not have been processed.

The usual approach to this challenge is to build a queue of outgoing responses. Adding a request to such a queue could be done using  fire and forget, whereby the user doesn't care when the request is completed, or to add a callback so that appropriate notifications (such as Email sent) can be communicated upon completion. Building queues like this with Go is well documented; support for multi-threading, channels, and wait groups makes it a relatively simple task so we'll not go into the details of how this could be executed. What's important, however, is determining whether a request succeeded or failed.

If an HTTP POST (for example) times out or returns with an error of 500 (or above), we must assume it failed. Re-issuing the same request is safe as re-issuing an identical POST shouldn't cause any additional state change if it was successfully completed the first time. A response code from 400 to 499 means that there was a fault with the request and re-trying won't fix the issue. In these cases, it's likely that the user needs to be informed of the failure (and the code should probably log the error to your team somehow).

Be careful not to blindly accept a status code of 200 (OK) as success; many protocols communicate certain failure conditions within the body of a successful HTTP response. Be sure to read the documentation for the API you're using to see how to check for additional errors. For example, a typical graphql response may return an HTTP status code 200 but have failed internally; knowing whether to retry in the background or to communicate the error to the application user will be specific to the service and the error encountered. In the following example, the server response helpfully indicated that a retry may help to resolve the issue:

{
  "errors" => [
    {
      "message" => "Temporary storage failure",
      "retry" => true,
      "path" => ["user", "add"],
    }
  ]
}