Código de resposta HTTP para POST quando o recurso já existe

842

Estou construindo um servidor que permite aos clientes armazenar objetos. Esses objetos são totalmente construídos no lado do cliente, completos com IDs de objeto que são permanentes por toda a vida útil do objeto.

Eu defini a API para que os clientes possam criar ou modificar objetos usando PUT:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

O {id} é o ID do objeto, portanto faz parte do Request-URI.

Agora, também estou pensando em permitir que os clientes criem o objeto usando POST:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

Como POST é uma operação "anexar", não tenho certeza do que fazer caso o objeto já esteja lá. Devo tratar a solicitação como solicitação de modificação ou devo retornar algum código de erro (qual)?

rest http http-status-codes

— vmj
fonte

5

Em junho de 2016, o FB descaradamente define 200 no registro quando o email existe

— Green

4

Github API retorna 422 ao tentar criar um recurso (equipe / repo) com um nome que já está em uso

— Ken

1

Depende se você considera a existência do objeto um erro ou não. Se você processar o anexo, 200 ou 204 são os códigos de resposta mais apropriados.

— precisa saber é o seguinte

1057

Meu sentimento é que 409 Conflicté o mais apropriado, porém, raramente visto na natureza, é claro:

A solicitação não pôde ser concluída devido a um conflito com o estado atual do recurso. Esse código é permitido apenas em situações em que se espera que o usuário possa resolver o conflito e reenviar a solicitação. O corpo da resposta DEVE incluir informações suficientes para que o usuário reconheça a fonte do conflito. Idealmente, a entidade de resposta incluiria informações suficientes para que o usuário ou agente do usuário corrija o problema; no entanto, isso pode não ser possível e não é necessário.

É provável que os conflitos ocorram em resposta a uma solicitação PUT. Por exemplo, se o controle de versão estava sendo usado e a entidade que estava sendo PUT incluía alterações em um recurso que entra em conflito com aquelas feitas por uma solicitação anterior (de terceiros), o servidor pode usar a resposta 409 para indicar que não pode concluir a solicitação . Nesse caso, a entidade de resposta provavelmente conteria uma lista das diferenças entre as duas versões em um formato definido pela resposta Content-Type.

— Wrikken
fonte

11

por que não optar por 400 pedidos inválidos? Para mim, isso parece um erro de validação (você está fornecendo carga útil incorreta com identificação ilegal).

— manuel aldana 30/09/10

314

400 => "A solicitação não pôde ser entendida pelo servidor devido à sintaxe malformada" . E o servidor entende perfeitamente, mas não consegue cumprir devido a um conflito. Não há nada errado com a solicitação e sintaxe, apenas um problema de dados. Um 400 me faria instantaneamente acreditar que todo o mecanismo que estou usando é defeituoso, em vez de apenas os dados.

— Wrikken 30/09/10

42

@Wrikken Isso não está mais correto. O HTTP 400 foi alterado no RFC 7231 para significar "o servidor não pode ou não processará a solicitação devido a algo que é percebido como um erro do cliente (por exemplo, sintaxe de solicitação malformada, enquadramento de mensagem de solicitação inválida ou roteamento de solicitação enganoso)". Não estou dizendo que 400 é o uso correto neste caso, mas poderia ser correta com a nova definição de 400.

— javajavajavajavajava

19

@javajavajavajavajava: ainda assim, dados duplicados não são um 'erro do cliente' em minha mente, mas isso está nos olhos de quem vê, é claro.

— Wrikken

21

Volto HTTP 409com um Locationcabeçalho apontando para o recurso existente / conflitante.

— Gili

100

De acordo com a RFC 7231 , um 303 Consulte Outros PODE ser usado Se o resultado do processamento de um POST for equivalente a uma representação de um recurso existente .

— Nullius
fonte

4

Na minha opinião, essa pode ser a resposta aceita. Embora "MAIO" indique um item completamente opcional, é o único código de resposta sugerido pela documentação oficial da RFC 7231 .

— Nando

16

Esta é a resposta mais RESTful.

— Seth

6

Eu acho que o contexto é importante. Por exemplo: retornar um 303 implica em um redirecionamento para o recurso encontrado. Isso pode fazer sentido em uma chamada de servidor para servidor, mas se você estivesse executando um processo de registro de usuário, não faria sentido algum.

— Sinaesthetic

11

Desculpe, estou votando contra isso. O HTTP 300s é sobre redirecionar, e redirecionar para outro objeto que provavelmente possui propriedades diferentes seria muito enganador.

— Michael Scheper

6

Você não precisa se desculpar. No entanto, se a representação é equivalente a um recurso existente, como ele pode ter propriedades diferentes? E mesmo que fosse, como um redirecionamento seria enganoso? O OP diz: Não tenho certeza do que fazer caso o objeto já esteja lá. Na verdade, é o 'mesmo' objeto. Por que um redirecionamento seria enganoso? Você está falando de outro objeto que, na mente do OP, claramente não é.

— Nullius

86

Pessoalmente, eu vou com a extensão WebDAV 422 Unprocessable Entity.

De acordo com a RFC 4918

O 422 Unprocessable Entitycódigo de status significa que o servidor entende o tipo de conteúdo da entidade de solicitação (portanto, um 415 Unsupported Media Typecódigo de status é inapropriado) e a sintaxe da entidade de solicitação está correta (portanto, um 400 Bad Requestcódigo de status é inadequado), mas não conseguiu processar as instruções contidas.

— Gareth
fonte

19

Esse é um pensamento interessante e me levou a finalmente ler o RFC do WebDAV. No entanto, acho que o significado de 422 é que a solicitação e a entidade incluída estavam sintaticamente corretas, mas semanticamente não faziam sentido.

— VMJ

4

Malformado JSON não é uma entidade sintaticamente correto, portanto, um 422me parece estranho ...

— awendt

7

Eu não iria com isso. Da mesma URL mencionada na resposta: "Por exemplo, essa condição de erro pode ocorrer se um corpo de solicitação XML contiver instruções XML bem formadas (ou seja, sintaticamente corretas), mas semanticamente erradas." Esse é o significado real de uma entidade não processável, diferente do caso em que você envia uma entidade de solicitação completamente válida com sintaxe e semântica válidas, mas o único problema é que ela entra em conflito com uma entidade existente. Na verdade, se a semântica da entidade solicitada não fosse válida, não deveria existir uma entidade existente semelhante.

— Tamer Shlash 04/12/2015

1

Adicionando ao comentário do Tamer, se a segunda solicitação vier primeiro, ela será bem-sucedida, o que não será possível se isso estiver semanticamente correto. Portanto, a semântica correta não se aplicaria aqui.

— Harish

4

@Tamer Por que? O comando "Crie o objeto xy" está sintaticamente correto. É semanticamente correto apenas se for possível criar o objeto xy. Se o objeto xy já existir, ele não poderá mais ser criado; portanto, esse é um erro semântico.

— Hagen von Eitzen

48

É tudo sobre contexto e também quem é responsável por lidar com duplicatas em solicitações (servidor ou cliente ou ambos)

Se o servidor apenas apontar a duplicata , veja 4xx:

400 Solicitação incorreta - quando o servidor não processa uma solicitação porque é uma falha óbvia do cliente
409 Conflito - se o servidor não processar uma solicitação, mas a razão para isso não for culpa do cliente
...

Para manipulação implícita de duplicatas, veja 2XX:

200 OK
201 Criado
...

se é esperado que o servidor retorne algo , veja 3XX:

302 Encontrados
303 Veja outros
...

quando o servidor é capaz de apontar o recurso existente, isso implica em um redirecionamento.

Se o exposto acima não for suficiente, é sempre uma boa prática preparar alguma mensagem de erro no corpo da resposta.

— Sławomir Lenart
fonte

2

A solicitação não está duplicando um recurso, está anexando dados a um. Na minha opinião, a sua é a melhor resposta de todas.

— Suncat2000

28

Talvez esteja atrasado para o jogo, mas me deparei com esse problema semântico enquanto tentava criar uma API REST.

Para expandir um pouco a resposta de Wrikken, acho que você pode usar qualquer uma delas, 409 Conflictou 403 Forbiddendependendo da situação - em resumo, use um erro 403 quando o usuário não puder fazer absolutamente nada para resolver o conflito e concluir a solicitação (por exemplo, não pode enviar um DELETEsolicitação para remover explicitamente o recurso) ou use 409 se algo puder ser feito.

10.4.4 403 Proibido

O servidor entendeu a solicitação, mas está se recusando a atendê-la. A autorização não ajudará e a solicitação NÃO DEVE ser repetida. Se o método de solicitação não foi HEAD e o servidor deseja tornar público o motivo pelo qual a solicitação não foi atendida, DEVE descrever o motivo da recusa na entidade. Se o servidor não desejar disponibilizar essas informações ao cliente, o código de status 404 (Não encontrado) poderá ser usado.

Atualmente, alguém diz "403" e um problema de permissão ou autenticação vem à mente, mas a especificação diz que é basicamente o servidor que diz ao cliente que não vai fazer isso, não pergunte novamente e é por isso que o cliente não deve 't.

Quanto a PUTvs. POST... POSTdeve ser usado para criar uma nova instância de um recurso quando o usuário não tem meios ou não deve criar um identificador para o recurso. PUTé usado quando a identidade do recurso é conhecida.

9.6 PUT

...

A diferença fundamental entre as solicitações POST e PUT é refletida no significado diferente do Request-URI. O URI em uma solicitação POST identifica o recurso que manipulará a entidade fechada. Esse recurso pode ser um processo de aceitação de dados, um gateway para outro protocolo ou uma entidade separada que aceita anotações. Por outro lado, o URI em uma solicitação PUT identifica a entidade incluída na solicitação - o agente do usuário sabe qual URI se destina e o servidor NÃO DEVE tentar aplicar a solicitação a algum outro recurso. Se o servidor desejar que a solicitação seja aplicada a um URI diferente,

DEVE enviar uma resposta 301 (movida permanentemente); o agente do usuário PODE então tomar sua própria decisão quanto a redirecionar ou não a solicitação.

— p0lar_bear
fonte

7

Eu acho que 403 Proibido implica que, mesmo que o usuário seja autenticado , ele não está autorizado a executar a ação solicitada. Eu não o usaria para erros de validação. Exemplo : Não logado, tento excluir algo. O servidor me envia 401 Não Autorizado (que está apenas com o nome incorreto, deve ser 401 Não Autenticado ). Eu entro e tento novamente. Desta vez, o servidor verifica minhas permissões, vê que não tenho permissão e retorna 403 Proibido . Veja também esta pergunta .

— Stijn de Witt

Hum ... verdade. O pensamento aqui foi direto ao dizer ao usuário que suas autorizações tornam o recurso imutável no caso de uso do OP - ele já existe, você não tem permissão para fazer nada para resolver o conflito, não tente criar o recurso novamente.

— p0lar_bear

3

De acordo com as especificações, está implícito que o erro 409 não pode ser retornado por uma POSTsolicitação (quando usado corretamente), pois indica que deve ser retornado quando entrar em conflito com o recurso de destino . Como o recurso de destino ainda não foi lançado, ele não pode entrar em conflito e, portanto, responder com 409 Conflictisso não faz sentido.

— Grant Gryczan

1

Eu não inferiria que um erro 409 não pode ser retornado por um POST, de fato, eu inferiria o contrário porque "É mais provável que os conflitos ocorram em resposta a uma solicitação PUT". parece indicar que outros métodos de solicitação também podem usar esse código. Além disso, "O corpo da resposta deve incluir informações suficientes para o usuário reconhecer a origem do conflito. Idealmente, a entidade de resposta incluiria informações suficientes para que o usuário ou o agente do usuário corrija o problema; no entanto, isso pode não ser possível e é não é necessário ". ( webdav.org/specs/rfc2616.html#status.409 )

— JWAspin

14

"302 encontrado" parece lógico para mim. E o RFC 2616 diz que PODE ser atendido para outros pedidos que não sejam GET e HEAD (e isso certamente inclui o POST)

Mas ainda mantém o visitante acessando este URL para obter esse recurso "Encontrado" pela RFC. Para fazê-lo ir diretamente para o URL "Encontrado" real, deve-se usar "303 See Other", o que faz sentido, mas força outra chamada a GET o seguinte URL. No lado bom, esse GET é armazenável em cache.

Eu acho que usaria "303 See Other" . Não sei se posso responder com a "coisa" encontrada no corpo, mas gostaria de fazer isso para salvar uma viagem de ida e volta ao servidor.

ATUALIZAÇÃO: Depois de reler o RFC, ainda acho que um código inexistente "4XX + 303 encontrado" deve estar correto. No entanto, o "409 Conflict" é o melhor código de resposta existente (como apontado por @Wrikken), talvez incluindo um cabeçalho Location apontando para o recurso existente.

— alanjds
fonte

88

Status 3xx são destinadas para redirecionamento

— Aviram Netanel

1

"O recurso solicitado reside temporariamente em um URI diferente." de w3.org/Protocols/rfc2616/rfc2616-sec10.html

— statueofmike

1

IMHO, "307 Redirecionamento temporário" é o redirecionamento temporário real. "302" é ambíguo, mas "ENCONTRADO !!" é a mensagem realmente desejada aqui. O melhor compromisso inequívoco é "303 Consulte outro" na semântica HTTP. Eu iria com "303 ver outros".

— Alanjds 22/08/14

@DavidVartanian Hum ... Não vejo erro aqui. O cliente envia uma solicitação correta, mas como dizer "Desculpe, mas o que você está tentando criar aqui já existe"? Parece um emprego para uns 3xx. Não é um 4xx para mim, pois não há erro do cliente.

— Alanjds 27/04/2015

1

@DavidVartanian Obrigado pela discussão. Atualizado a resposta para 409 . O cliente está errado ao pedir coisas impossíveis, mesmo que não saiba que é impossível.

— Alanjds

11

Eu não acho que você deveria fazer isso.

O POST é, como você sabe, modificar a coleção e é usado para criar um novo item. Portanto, se você enviar o ID (acho que não é uma boa ideia), modifique a coleção, ou seja, modifique o item, mas é confuso.

Use-o para adicionar um item, sem identificação. É a melhor prática.

Se você deseja capturar uma restrição UNIQUE (não o ID), pode responder 409, como é possível nas solicitações PUT. Mas não o ID.

— Alfonso Tienda
fonte

E quanto a um objeto que tenha uma relação de tabela de junção? Digamos que temos conta, produto e account_product como tabelas do banco de dados. Quero adicionar um produto a uma conta, portanto, gostaria de postar em / account / {id} / product com o product_id. Se apenas um relacionamento conta-produto for permitido, o que devo retornar?

— precisa saber é o seguinte

2

Esqueça as tabelas do banco de dados. Digamos que um produto possa estar relacionado apenas a uma conta ... Então é um relacionamento entre muitos. Portanto, POST / product / {id} com {'account': account_id}. Se você tem a cardinalidade máxima definida como '1' (relacionamento de um para um) ... Por que eles são objetos de descanso separados? Um erro de cardinalidade será apenas um erro de 400. Mantenha simples. Espero ter entendido sua pergunta.

— Alfonso Tienda 10/10

Também fiz essa pergunta e, para mim, o ID não é o ID técnico no banco de dados, mas algo como a empresa. Nesta aplicação, um usuário gerente pode criar empresas e precisa fornecer um código a elas. Este é o ID da empresa para o usuário, apesar de a tabela DB também possuir um ID técnico. Portanto, no meu caso, retornarei um 409 se a mesma empresa já existir.

— AlexCode #

@partkyle Pare de usar PKs como identificações públicas !!

— Sinaesthetic

Algumas entidades têm restrições exclusivas, não apenas o ID. Como uma conta, você não pode criar uma conta se o usuário não fornecer o nome de usuário. E adicionando uma conta com nenhum nome de usuário é obviamente impossível

— rocketspacer

9

Eu iria com 422 Unprocessable Entity, que é usado quando uma solicitação é inválida, mas o problema não está na sintaxe ou na autenticação.

Como argumento contra outras respostas, usar qualquer 4xxcódigo que não seja de erro implicaria que não é um erro do cliente, e obviamente é. Usar um 4xxcódigo que não seja erro para representar um erro do cliente simplesmente não faz sentido.

Parece que 409 Conflicté a resposta mais comum aqui, mas, de acordo com as especificações, isso implica que o recurso já existe e que os novos dados que você está aplicando são incompatíveis com seu estado atual. Se você estiver enviando umPOSTsolicitar, com, por exemplo, um nome de usuário que já seja usado, na verdade não esteja em conflito com o recurso de destino, pois o recurso de destino (o recurso que você está tentando criar) ainda não foi publicado. É um erro especificamente para o controle de versão, quando há um conflito entre a versão do recurso armazenado e a versão do recurso solicitado. É muito útil para esse fim, por exemplo, quando o cliente armazena em cache uma versão antiga do recurso e envia uma solicitação com base nessa versão incorreta que não seria mais válida condicionalmente. "Nesse caso, a representação da resposta provavelmente conteria informações úteis para mesclar as diferenças com base no histórico de revisões." A solicitação para criar outro usuário com esse nome de usuário não é processável, não tendo nada a ver com o controle de versão.

Para o registro, 422 também é o código de status que o GitHub usa quando você tenta criar um repositório com um nome já em uso.

— Grant Gryczan
fonte

422 é webdav spec, então eu não recomendaria usá-lo para uma API REST

— rwenz3l

7

Penso que, para o REST, você só precisa tomar uma decisão sobre o comportamento desse sistema específico. Nesse caso, acho que a resposta "certa" seria uma das poucas respostas dadas aqui. Se você deseja que a solicitação pare e se comporte como se o cliente tivesse cometido um erro que precisa corrigir antes de continuar, use 409. Se o conflito realmente não é tão importante e deseja manter a solicitação, responda redirecionando o cliente para a entidade que foi encontrada. Acho que as APIs REST adequadas devem ser redirecionadas (ou pelo menos fornecer o cabeçalho do local) para o ponto de extremidade GET para esse recurso após um POST de qualquer maneira, para que esse comportamento proporcione uma experiência consistente.

EDIT: Também vale a pena notar que você deve considerar um PUT, pois está fornecendo o ID. Então o comportamento é simples: "Eu não me importo com o que há agora, coloque isso aí". Ou seja, se não houver nada, ele será criado; se algo estiver lá, será substituído. Eu acho que um POST é mais apropriado quando o servidor gerencia esse ID. A separação dos dois conceitos basicamente mostra como lidar com ele (por exemplo, PUT é idempotente, portanto, ele deve sempre funcionar enquanto a carga útil valida, o POST sempre cria; portanto, se houver uma colisão de IDs, um 409 descreveria esse conflito) .

— Sinaesthetic
fonte

De acordo com as especificações, está implícito que o erro 409 não pode ser retornado por uma POSTsolicitação (quando usado corretamente), pois afirma que deve ser retornado quando entrar em conflito com o recurso de destino . Como o recurso de destino ainda não foi lançado, ele não pode entrar em conflito e, portanto, responder com 409 Conflictnão faz sentido.

— Grant Gryczan

Imo discutível. Se você postar em / users, o recurso será a coleção em vez do registro individual / users / {id} #

— Sinaesthetic

É um erro especificamente para o controle de versão, quando há um conflito entre a versão do recurso armazenado e a versão do recurso solicitado. É muito útil para esse propósito, por exemplo, quando o cliente armazena em cache uma versão antiga do recurso e envia uma solicitação com base nessa versão incorreta que não seria mais válida condicionalmente. "Nesse caso, a representação da resposta provavelmente conteria informações úteis para mesclar as diferenças com base no histórico de revisões."

— Grant Gryczan

Eu gosto da sua sugestão de usar PUT.

— Grant Gryczan

4

Outro tratamento potencial é usar PATCH, afinal. Um PATCH é definido como algo que altera o estado interno e não se restringe a anexar.

PATCH resolveria o problema, permitindo a atualização de itens já existentes. Consulte: RFC 5789: PATCH

— Martin Kersten
fonte

2

O patch é como PUT, mas não é um substituto completo. É usado para modificar uma parte do recurso, como adicionar, remover ou modificar um único elemento do recurso, em vez de substituí-lo como um todo.

— Sinaesthetic

4

Por que não um 202 aceito ? É uma solicitação OK (200s), não houve erros do cliente (400s), por si só.

De 10 definições de código de status :

"202 Aceito. A solicitação foi aceita para processamento, mas o processamento não foi concluído."

... porque não precisava ser concluída, porque já existia. O cliente não sabe que já existia, não fez nada de errado.

Estou apostando em lançar um 202 e retornar um conteúdo semelhante ao que um GET /{resource}/{id}teria retornado.

— Phillip Harrington
fonte

21

Esta resposta está errada. 202 significa que o servidor não encontrou um problema com a solicitação, mas optou por processá-la após responder. Isso também significa que espera que o processamento seja bem-sucedido. No nosso caso, o servidor sabe que o processamento falhará, então 202 é a resposta errada.

— Adrian

4

Um exemplo de 202 seria uma fila ou assinatura. Em outras palavras, o resultado da solicitação pode não estar disponível imediatamente se você a consultar neste momento.

— Sinaesthetic

1

Isso seria apropriado se o servidor ainda estivesse processando a solicitação. 200 ou 204 seria mais comum. Como o OP está fazendo uma solicitação de acréscimo, a existência do objeto é uma condição esperada e não um erro.

— precisa saber é o seguinte

Não faz sentido dizer ao cliente que a solicitação foi aceita porque você já sabe que não foi!

— Lucastamoios # 5/19

1

@ Adrian e lucastamoios Eu acho que vocês dois estão assumindo que o servidor lê sincronamente do banco de dados, antes de fornecer a resposta. Esse nem sempre é o caso, portanto, essa resposta não está "errada", pois o servidor nem sempre "sabe" sobre o registro existente. Esse é o caso de sistemas assíncronos em que a camada api simplesmente registra as solicitações de processamento pelos trabalhadores em segundo plano.

— gsaslis

2

Tropecei nessa pergunta enquanto verifica o código correto para o registro duplicado.

Perdoe minha ignorância, mas não entendo por que todo mundo está ignorando o código "300", que diz claramente "múltipla escolha" ou "ambíguo"

Na minha opinião, esse seria o código perfeito para criar um sistema não padrão ou particular para seu próprio uso. Eu também poderia estar errado!

https://tools.ietf.org/html/rfc7231#section-6.4.1

— Bater em
fonte

Meu entendimento: "o código de status indica que o recurso de destino tem mais de uma representação ... informações sobre as alternativas estão sendo fornecidas para que o usuário (ou agente do usuário) possa selecionar uma representação preferida redirecionando sua solicitação para um ou mais desses identifiers "Estamos tentando explicitamente impedir mais de uma representação. Não há opções. Não há alternativas para o cliente escolher. O cliente deve reenviar com um ID diferente. Com isso dito, deve-se considerar também se IDs únicos devem ser gerados no cliente versus servidor.

— musicin3d

Semanticamente, o cliente está dizendo "Crie isto" e o servidor está respondendo dizendo "Vá aqui em vez disso". A conversa não faz nenhum sentido. É quase como se o servidor estivesse dizendo ao cliente para "postar neste local". Os 300s são mais uma resposta mais apropriada a uma solicitação GET ou POST no caso em que o servidor está respondendo com "Ok, eu criei e já está aqui".

— Sinaesthetic

2

Mais provavelmente é 400 Bad Request

6.5.1 400 Solicitação incorreta

O código de status 400 (Solicitação incorreta) indica que o servidor não pode ou não processará a solicitação devido a algo que é considerado um erro do cliente (por exemplo, sintaxe de solicitação malformada, enquadramento de mensagem de solicitação inválida ou roteamento de solicitação enganoso).

Como a solicitação contém valor duplicado (valor que já existe), ela pode ser percebida como um erro do cliente. Precisa alterar a solicitação antes da próxima tentativa.
Ao considerar esses fatos, podemos concluir como HTTP STATUS 400 Bad Request.

— Mohammed Safeer
fonte

1

Solicitação incorreta significa que há um problema inerente à sintaxe do pacote. Se, em outro contexto (como o recurso ainda não existente), o pacote teria sucesso, então ele não deve retornar erro 400.

— Grant Gryczan

1

E o 208 - http://httpstatusdogs.com/208-already-reported ? Isso é uma opção?

Na minha opinião, se a única coisa é um recurso repetido, nenhum erro deve ser gerado. Afinal, não há erro nem no lado do cliente nem no servidor.

— Fernando Ferreira
fonte

Esta não é uma opção, porque você deseja anexar um determinado item cujo ID já existe. Então você tenta adicionar algo, mas isso já está lá. Um OK seria aplicado apenas se o conjunto de dados fosse aumentado. Anexar algo -> Ok, eu não anexei nada. Não se encaixa, eu acho.

— Martin Kersten

Como eu disse, não acho que isso seja um erro. Mas eu vejo o objetivo de @martin

— Fernando Ferreira

Se o recurso não for criado com êxito, haverá, por definição, um erro.

— Grant Gryczan

O POST também é usado para anexar dados. Isso é por definição , não um erro .

— precisa saber é o seguinte

@ Suncat2000 Mesmo se for esse o caso, se os dados não forem anexados com sucesso, ainda há um erro. E se o recurso já existir, nenhum dado será anexado.

— Grant Gryczan

0

No seu caso, você pode usar 409 Conflict

E se você quiser verificar outros HTTPscódigos de status da lista abaixo

1 ×✓ Informativo

100 Continue
101 Switching Protocols
102 Processing

2 ×✓ Sucesso

200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

Redirecionamento 3x ×

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect

Erro × Cliente × ×

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request

Erro de servidor 5 ×✓

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error

— Abd Abughazaleh
fonte