2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
|
set: 4
|
|
|
|
|
code: 409
|
|
|
|
|
title: Conflict
|
2015-11-07 05:34:40 +01:00
|
|
|
references:
|
|
|
|
|
"Rails HTTP Status Symbol": ":conflict"
|
2015-11-06 21:39:33 +01:00
|
|
|
---
|
|
|
|
|
|
2015-11-07 06:45:46 +01:00
|
|
|
The 409 Conflict status code indicates that the request could not be completed
|
2015-11-07 05:34:40 +01:00
|
|
|
due to a conflict with the current state of the target resource. This code is
|
|
|
|
|
used in situations where the user might be able to resolve the conflict and
|
2015-11-07 06:45:46 +01:00
|
|
|
resubmit the request.
|
|
|
|
|
|
|
|
|
|
The server SHOULD generate a payload that includes enough information for a user
|
|
|
|
|
to recognize the source of the conflict.
|
2015-11-07 05:34:40 +01:00
|
|
|
|
|
|
|
|
Conflicts are most likely to occur in response to a PUT request. For example, if
|
|
|
|
|
versioning were being used and the representation being PUT included changes to
|
|
|
|
|
a resource that conflict with those made by an earlier (third-party) request,
|
|
|
|
|
the origin server might use a 409 response to indicate that it can't complete
|
|
|
|
|
the request. In this case, the response representation would likely contain
|
|
|
|
|
information useful for merging the differences based on the revision history.
|
|
|
|
|
|
|
|
|
|
Source: [RFC7231 Section 6.5.8][1]
|
|
|
|
|
|
|
|
|
|
[1]: <http://tools.ietf.org/html/rfc7231#section-6.5.8>
|
