title: Making PUT create request idempotent in REST API
body: <p>My goal is to make idempotent /create REST API which is implemented as PUT verb.</p>
  <p><a href="https://www.rfc-editor.org/rfc/rfc7231#section-4.2.2" rel="nofollow noreferrer">Idempotent RFC </a>  states:</p>
  <blockquote>
  <p>Idempotent methods are distinguished because the request can be<br />
  repeated automatically if a communication failure occurs before the<br />
  client is able to read the server's response.  For example, if a<br />
  client sends a PUT request and the underlying connection is closed<br />
  before any response is received, then the client can establish a new<br />
  connection and retry the idempotent request.  It knows that repeating
  the request will have the same intended effect, even if the original<br />
  request succeeded, though the response might differ.</p>
  </blockquote>
  <p><a href="https://www.rfc-editor.org/rfc/rfc7231#section-4.3.4" rel="nofollow noreferrer">PUT RFC</a> states:</p>
  <blockquote>
  <p>If the target resource does not have a current representation and the
  PUT successfully creates one, then the origin server MUST inform the<br />
  user agent by sending a 201 (Created) response.  If the target<br />
  resource does have a current representation and that representation<br />
  is successfully modified in accordance with the state of the enclosed
  representation, then the origin server MUST send either a 200 (OK) or
  a 204 (No Content) response to indicate successful completion of the<br />
  request.</p>
  </blockquote>
  <p>Assuming that /create stores the created resource in DB, should it return 201 on first creation and 200 on retried /create?
  Should retried /create store the same resource in DB all over again to conform with PUT RFC?</p>