Código de status HTTP para atualização e exclusão?

Qual código de status devo definir para UPDATE( PUT) e DELETE(por exemplo, produto atualizado com sucesso)?

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".

COLOCAR

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.

EXCLUIR

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

Origem: Lista de códigos de status HTTP: 2xx Success

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).

Fonte: https://github.com/for-GET/http-decision-diagram

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.

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

Em junho de 2014, o RFC7231 obsoleta o RFC2616. Se você estiver executando o REST sobre HTTP, o RFC7231 descreve exatamente o comportamento esperado de GET, PUT, POST e DELETE

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