What is standard HTTP error code when a resource already exists ?

[navyad]

I'm having an issue for deciding the HTTP response code for a resource which already exists in the system.

I have my inclination towards the HTTP 409 by sheer technical definition of it. Not sure how API calls of libraries like github, twitter etc handles the issue.

Needs to know what is the standard way to handle this.

Thanks 

[sune jakobsson]

You only give 4xx if there is something WRONG with the input, and 5xx if the underlying has disappeared.

2xx is a suitable response in your case.

Sune

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Johan Groenen]

What call are you trying to make?

[Andy Dennie]

If a client is POST-ing a resource representation that contains some value which must be unique across all such resources, but which conflicts with another existing resource, then I think a 409 is appropriate.  Likewise if the client is PUT-ing a resource representation which conflicts with a different resource.

For example, say there you have Book resources (e.g. /books/12345, /books/67890, etc), each with ISBN values.  If a client tries to POST a book representation to the /books collection resource and that provided representation specifies an ISBN associated with an existing book resource, then a 409 would be appropriate, IMHO.  Similarly if a client tries to PUT a book representation to an existing book resource, and the ISBN in the provided representation conflicts with a different book resource, then 409 makes sense.

[Felipe Seré]

I’d only use 409 and 412 in combination with eTags.
In this case I’d probably go with a 400 Bad Request and add a reference to the invalid property in the body.

On 21 January 2015 at 15:57:29, Andy Dennie (goo...@adennie.e4ward.com) wrote:

If a client is POST-ing a resource representation that contains some value which must be unique across all such resources, but which conflicts with another existing resource, then I think a 409 is appropriate.  Likewise if the client is PUT-ing a resource representation which conflicts with a different resource.

For example, say there you have Book resources (e.g. /books/12345, /books/67890, etc), each with ISBN values.  If a client tries to POST a book representation to the /books collection resource and that provided representation specifies an ISBN associated with an existing book resource, then a 409 would be appropriate, IMHO.  Similarly if a client tries to PUT a book representation to an existing book resource, and the ISBN in the provided representation conflicts with a different book resource, then 409 makes sense.

[Atif Haider]

My 2 cents:

This is how Github works while "Creating a Repository with the repo 'name' which already exists on your account"

Create a repo API endpoint: https://developer.github.com/v3/repos/#create

Request & Response: PFA (Request/Response from Github.png).

So, Github returns 422 when a record already exists. Here is details on Error codes from Github: https://developer.github.com/v3/#client-errors

In my understand, 409 can be used when we try to "edit an existing record" with an older version of the same record. For instance: While making a PUT request to upload a file where the resource has already got a file which is newer (could be based on timestamp etc) than the requested one then the API returns 409.

Let's try another example: How Heroku works while "Creating an app with the app 'name' which already exists on your account"

Create an app API endpoint: https://devcenter.heroku.com/articles/platform-api-reference#app-create

Request & Response: PFA. (Request/Response from Heroku.png)

So, Heroku returns 422 when a record already exists. Here is the detail on Error/Response codes from Heroku: https://devcenter.heroku.com/articles/platform-api-reference#client-error-responses

Therefore, it seems 422 is the code, IMHO. Open for debate. :)

[Andy Dennie]

Upon further review, I retract my suggestion - 409 indicates a conflict with the existing state of the resource, not a conflict with a different resource.

-Andy