Qual código de status devo definir para UPDATE( PUT) e DELETE(por exemplo, produto atualizado com sucesso)?
Código de status HTTP para atualização e exclusão?
Respostas:
Para uma solicitação PUT : HTTP 200 ou HTTP 204 deve implicar "recurso atualizado com sucesso".
Para uma solicitação DELETE : HTTP 200 ou HTTP 204 deve implicar "recurso excluído com sucesso". O HTTP 202 também pode ser retornado, o que implicaria que a instrução foi aceita pelo servidor e o "recurso foi marcado para exclusão".
Se um recurso existente for modificado, os códigos de resposta 200 (OK) ou 204 (sem conteúdo)> DEVEM ser enviados para indicar a conclusão bem-sucedida da solicitação.
Uma resposta bem-sucedida DEVE ser 200 (OK) se a resposta incluir uma entidade que descreve o status, 202 (Aceito) se a ação ainda não foi promulgada ou 204 (Sem Conteúdo) se a ação foi promulgada, mas a resposta não incluir uma entidade.
Fonte: W3.org: Definições de método HTTP / 1.1
HTTP 200 OK: resposta padrão para solicitações HTTP bem-sucedidas. A resposta real dependerá do método de solicitação usado.
HTTP 204 sem conteúdo: o servidor processou a solicitação com êxito, mas não está retornando nenhum conteúdo
40
Post muito útil! No entanto, eu estou querendo saber qual deve ser o código de status HTTP. A solicitação enviada pelo cliente é válida (DELETE mySite / entity / 123 ) e a entidade a ser excluída não existe.
—
Martin
@ Martin: Nesse caso, o serviço deve retornar um HTTP 404. Estritamente falando, uma solicitação DELETE ou GET para um recurso que não existe não é uma solicitação "válida" - ie. o cliente não deve tentar novamente essa solicitação porque nunca terá êxito ... O protocolo HTTP define duas categorias de problemas - aqueles com um código de status 4xx, em que o cliente deve modificar a solicitação antes de tentar novamente e aqueles com status 5xx código, que indica que o serviço teve problemas e o cliente deve / poderia repetir a mesma solicitação exata sem alterá-la.
—
Daniel Vassallo
@JeffMartin Isso pode ser assim a partir do ponto de vista do usuário, mas, tanto quanto o servidor está em causa, se o recurso não existir, o servidor deve retornar 404.
—
Randolpho
@ Randolpho, Idempotence tem tudo a ver com obter o mesmo resultado, independentemente de você invocar uma operação uma ou várias vezes. O cliente está pedindo para garantir que o recurso seja excluído. Qual é o benefício de retornar 404? Por que ele precisa saber de qualquer maneira? Agora a lógica do cliente precisa manipular dois códigos de resposta separados em vez de um.
—
Gili
@ Gili: talvez o wiki explique melhor: Métodos PUT e DELETE são definidos como idempotentes ... observe que idempotência refere-se ao estado do sistema após a conclusão da solicitação, enquanto a ação do servidor (por exemplo, excluir um registro) ) ou o código de resposta que ele retornar pode ser diferente em solicitações subsequentes; o estado do sistema será o mesmo sempre.
—
Randolpho
Resposta curta: para PUT e DELETE, você deve enviar 200 (OK) ou 204 (sem conteúdo).
Resposta longa: aqui está um diagrama de decisão completo (clique para ampliar).
O diagrama é incrível. Existe uma versão com resolução mais alta para impressão?
—
KiKi
No contexto do POST de um recurso existente, outra discussão do SO ( stackoverflow.com/questions/3825990/… ) sugere enviar 409 Conflict ou 302 Found em vez de anexar o conteúdo.
—
koppor
Estou curioso para saber se as respostas 204 e 200 após a exclusão devem ser revertidas e se estão corretas como estão, por quê? Excluído? -> Resposta inclui uma entidade? -> sim -> 204 sem conteúdo; no -> 200 OK
—
mat 9/09/13
Versão atualizada da imagem é aqui: raw.github.com/for-GET/http-decision-diagram/master/httpdd.png
—
Zaius
Está faltando PATCH.
—
21414
Aqui estão algumas dicas:
EXCLUIR
200 (se desejar enviar alguns dados adicionais na resposta) ou 204 (recomendado).
202 A operação excluída ainda não foi confirmada.
Se não houver nada para excluir, use 204 ou 404 (a operação DELETE é idempotente, excluir um item já excluído é uma operação bem-sucedida , portanto, você pode retornar 204 , mas é verdade que idempotent não implica necessariamente a mesma resposta)
Outros erros:
- 400 Solicitação incorreta (sintaxe mal formada ou uma consulta incorreta é estranha, mas possível).
- 401 Falha na autenticação não autorizada
- 403 Proibido : falha na autorização ou ID do aplicativo inválido.
- 405 Não permitido . Certo.
- 409 Conflito de recursos pode ser possível em sistemas complexos.
- E 501 , 502 em caso de erros.
COLOCAR
Se você estiver atualizando um elemento de uma coleção
- 200/204 pelos mesmos motivos que DELETE acima.
- 202 se a operação ainda não foi confirmada.
O elemento referenciado não existe:
- PUT pode ser 201 (se você criou o elemento porque esse é o seu comportamento)
404 Se você não deseja criar elementos via PUT.
400 Solicitação incorreta (sintaxe mal formada ou uma consulta incorreta mais comum do que no caso de DELETE).
- 401 Não autorizado
- 403 Proibido : falha na autenticação ou ID do aplicativo inválido.
- 405 Não permitido . Certo.
- 409 Conflito de recursos pode ser possível em sistemas complexos, como em DELETE.
- 422 Entidade não processável Ajuda a distinguir entre uma "Solicitação incorreta" (por exemplo, XML / JSON malformado) e valores de campo inválidos
- E 501 , 502 em caso de erros.
Essa resposta é composta quase inteiramente por duas grandes aspas, mas não há atribuição. De onde você está citando?
—
Quentin
204 é um status adequado para retornar para uma solicitação PUT, se o estado não for alterado efetivamente? Por exemplo, você pede para desativar um usuário, mas o usuário já está inativo.
—
Ε Г И І И О
A solicitação PUT é idempotente, portanto, você pode retornar um 204, porque o objeto foi alterado no sistema. PUT não é PATCH; portanto, você não tem certeza de qual campo deseja alterar. Você pode enviar de volta um 501 - 502, se o seu design precisar saber se o objeto era exatamente o mesmo que o objeto da solicitação, mas ... eu realmente não gosto .. prefiro 204 ou, se você quiser desativar um usuário, sem alterar mais campos, talvez você possa usar PATCH.
—
Alfonso Tienda
Eu adicionaria HTTP 422 Unprocessable Entity. Ajuda a distinguir entre uma "Solicitação incorreta" (por exemplo, XML / JSON malformado) e valores de campo inválidos.
—
precisa
O RFC 2616 descreve quais códigos de status usar .
E não, nem sempre é 200.
Além de 200 e 204, 205 (Redefinir conteúdo) poderia ser uma resposta válida.
O servidor atendeu à solicitação e o agente do usuário DEVE redefinir a exibição do documento que causou a solicitação a ser enviada ... [por exemplo] limpeza do formulário no qual a entrada é fornecida.
Como a pergunta investiga se DELETE "deveria" retornar 200 vs 204 , vale a pena considerar que algumas pessoas recomendam retornar uma entidade com links, portanto a preferência é por 200 .
"Em vez de retornar 204 (sem conteúdo), a API deve ser útil e sugerir locais a seguir. Neste exemplo, acho que um link óbvio a ser fornecido é" 'somewhere.com/container/' (menos 'recurso') "- o contêiner do qual o cliente acabou de excluir um recurso. Talvez o cliente deseje excluir mais recursos, o que seria um link útil ".
http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/
Se um cliente encontrar uma resposta 204, ele poderá desistir, acessar o ponto de entrada da API ou retornar ao recurso anterior que visitou. Nenhuma das opções é particularmente boa.
Pessoalmente, eu não diria que 204 está errado (nem o autor; ele diz "irritante") porque um bom cache no lado do cliente tem muitos benefícios. O melhor é ser consistente de qualquer maneira.
Aqui está um código de status, que você deve conhecer para o seu tipo de conhecimento.
1XX Respostas de informações
- 100 Continuar
- 101 Protocolos de comutação
- 102 Processamento
- 103 Dicas iniciais
2XX Success
- 200 OK
- 201 Criado
- 202 Aceito
- 203 Informações Não Autorizadas
- 204 Sem Conteúdo
- 205 Redefinir conteúdo
- 206 Conteúdo Parcial
- 207 Multi-Status
- 208 já relatados
- 226 IM Usado
Redirecionamento 3XX
- 300 escolhas múltiplas
- 301 movido permanentemente
- 302 Encontrados
- 303 Veja Outros
- 304 Não modificado
- 305 Usar proxy
- 306 Switch Proxy
- 307 Redirecionamento temporário
- Redirecionamento permanente 308
Erros de cliente 4XX
- 400 Solicitação incorreta
- 401 Não autorizado
- 402 Pagamento obrigatório
- 403 Proibido
- 404 não encontrado
- 405 Método não permitido
- 406 Não aceitável
- 407 autenticação de proxy necessária
- 408 Tempo limite da solicitação
- 409 Conflito
- 410 Gone
- 411 Comprimento necessário
- Falha na pré-condição 412
- 413 Carga útil muito grande
- URI 414 muito longo
- 415 Tipo de mídia não suportado
- 416 Faixa Não Satisfatória
- 417 Expectativa falhada
- 418 eu sou um bule de chá
- Falha no método 420
- 421 Solicitação mal direcionada
- 422 Entidade não processável
- 423 Bloqueado
- 424 Dependência com falha
- 426 Atualização necessária
- 428 Pré-requisito necessário
- 429 Solicitações em excesso
- 431 Campos do cabeçalho da solicitação muito grandes
- 451 Indisponível por motivos legais
Erros de servidor 5XX
- Erro 500 interno do servidor
- 501 Não implementado
- 502 Bad Gateway
- 503 Serviço indisponível
- Tempo limite do gateway 504
- Versão 505 HTTP não suportada
- 506 Varient Também negociar
- 507 Armazenamento insuficiente
- 508 Loop Detectado
- 510 Não estendido
- 511 Autenticação de rede necessária
Quando um recurso é modificado, o código de resposta deve ser 200 ("OK") . Se o estado do recurso mudar de uma maneira que altere o URI para o recurso (por exemplo, uma conta de usuário seja renomeada), o código de resposta será 301 ("Movido permanentemente") e o cabeçalho Local deverá fornecer o novo URI.
Quando um objeto é excluído, o código de resposta deve ser 200 ("OK").
Siga o link abaixo para obter mais detalhes - código de status para descanso