Photo por Kristina Tripkovic no Unsplash
No último artigo, vimos muitos dos códigos de status HTTP mais comuns e definimos muitas coisas, como o que é um código de status, como eles funcionam e por que são tão importantes. Agora, vamos dar uma olhada em outros códigos de status que não vemos muito, mas que deveriam ser usados mais.
Além disso, continuaremos usando gatos e cachorros para ilustrar nossos códigos \o/
Sumário
Códigos que não vemos muito, mas que deveríamos
Agora estamos indo para o mundo perfeito, onde falamos sobre os códigos que não são vistos muito na natureza, mas estão lá e devem ser usados com mais frequência.
200x
202 - Accepted
Este é um código de status assíncrono, afirma que a solicitação foi aceita, mas não diz nada sobre o estado real de processamento de tal solicitação, nem sobre o resultado daquilo que pode acontecer em outro servidor. O servidor deve fornecer, em um cabeçalho ou por qualquer outro meio, um ponteiro para um monitor de status que apresentará ao usuário o status da solicitação enviada anteriormente.
Quando usá-lo: Esta é a clássica "fila" quando temos um recurso que deve ser colocado na fila para processamento posterior. O código de status 202 indica que o recurso foi aceito, portanto está tudo bem com a solicitação, não pode ser processado agora, mas será concluído em algum momento. Isso geralmente é usado para processamento em lote ou algum tipo de operação intensiva da CPU, enviamos a solicitação que precisa ser processada e, em troca, obtemos um link do monitor de status. Os Serviços Cognitivos da Azure possuem APIs como esta.
204 - No Content
Este é o código de status mais simples, mas o mais não utilizado. Significa apenas que está tudo bem, mas não há nada a dizer sobre isso ...
Quando usá-lo: Prefiro usá-lo em solicitações DELETE, pois esses tipos de solicitações fazem o que devem fazer e nada mais. Por exemplo, DELETE /user/1234 deve excluir o usuário, a maioria das pessoas retorna um código de status 200, mas esse código implica que alguma resposta viria com ele, em uma declaração DELETE isso não existe, não temos mais nada a dizer sobre isso, o recurso foi apenas... Excluído...
205 - Reset Content
Então ... não encontrei uma imagem de gato ou cachorro para colocar aqui e ilustrar esse código... MAS! O código 205 é definido no RFC7231 e indica uma das coisas mais usadas no passado - e no presente - postbacks! Sintetizando, ele diz que a solicitação foi processada e o usuário deve atualizar a página para ver essa alteração.
Quando usá-lo: Com SPAs esse código caiu no esquecimento hoje em dia, já que a última coisa que um SPA faz é atualizar a página (afinal, é um aplicativo de página única...). Mas, às vezes, estamos lidando com casos 202 e poderíamos ter um monitor de status que nos mostrasse se o processo foi concluído ou não. Se o recurso ainda estiver em processamento, ele deverá retornar 202, caso contrário, 205!
206 - Partial Content
Este é o meu código de status favorito, não apenas porque não o vemos com muita frequência e é muito fácil de entender, mas também porque indica claramente o que significa e pode ajudar muito se for mais usado! O código 206 afirma que o conteúdo que está sendo enviado de volta não é o conteúdo inteiro que o servidor possui para esse recurso. Opcionalmente, isso é uma resposta a um cabeçalho Range enviado pelo cliente. Os Serviços de Armazenamento do Azure usa esse cabeçalho com frequência.
Quando usá-lo: Eu gosto de usá-lo ao executar consultas do tipo search, por exemplo, uma consultaGET /users, essa é obviamente uma lista de usuários que não posso retornar por por completo, pois pode pesar uma tonelada, então eu pagino. A primeira vez que um usuário faz a solicitação, o servidor responde um 206 com um cabeçalho personalizado que eu gosto de chamar de X-Content-Range que possui de-para/total; em seguida, temos duas opções:
- O usuário faz uma request
GET /users?page=2 - O usuário faz uma request
GET /userscom um cabeçalhoRange: <número da página>
Em seguida, o servidor responderá com 206 até que não haja mais páginas; na última página, ele responderá 200, se o usuário tentar acessar uma página fora do intervalo, retornarei um 204 (se eu não quiser causar pânico) ou um 416.
300x
303 - See Other
O código de status See Other refere-se à segunda parte de uma solicitação POST ouPUT quando criamos o recurso e ele ficar acessível através de outra URI, o servidor deverá então enviar um cabeçalho Location informando onde o novo recurso pode ser encontrado.
Quando usá-lo: Você pode usar o código de status 202 quando estiver falando de um documento criado, mas o usuário não precisa vê-lo ou o aplicativo não precisa levar o usuário para a página do recurso. Em todas as outras situações, use 303.
304 - Not Modified
O código de status "not modified" é um pouco complicado devido às suas possibilidades, no entanto, de acordo com a declaração padrão de sua definição, esse status deve ser retornado quando o cliente fizer uma request com os cabeçalhos If-Modified-Since ouIf-None-Match e o servidor não encontrar nenhum recurso modificado.
Quando usá-lo: Eu gosto de usá-lo de maneira diferente, normalmente retorno 304 se o documento alterado por uma solicitação PUT ouPATCH não sofreu nenhuma modificação, isso é útil para definir se devemos recarregar ou não é a página.
Essa é uma opinião pessoal, sei que não é assim que o código 304 deve ser usado, mas me serve muito bem assim.
307 - Temporary Redirect
Este código de status é praticamente o mesmo que 302, a única diferença é que o 302 permite a alternância de método HTTP entre chamadas, isso significa que eu posso executar uma solicitação GET na primeira request, receba um 302 e, em seguida, execute um PUT no terminal especificado retornado pelo servidor. Com 307 isso é proibido, você deve executar a solicitação com o mesmo método.
Quando usá-lo: Os mesmos casos que 302, mas mais rigoroso (eu o usaria sempre).
308 - Permanent Redirect
Este código de status é definido no RFC7538, é o mesmo caso de 307, mas em vez de substituir o 302, ele substitui o 301, todas as outras informações são exatamente as mesmas.
Quando usá-lo: Os mesmos casos que 301, mas mais rigoroso (eu o usaria sempre).
400x
409 - Conflict
Esse código de status pode ser visto na Internet eventualmente, mas eu gostaria que estivesse mais presente... O código 409 indica um conflito no estado do recurso, isso pode ser causado devido a uma atualização simultânea ou se você estiver tentando inserir algo que já existe.
Quando usá-lo: Geralmente, eu o uso ao fazer solicitações POST, se o recurso já existir, retorno 409, por exemplo, um usuário com o mesmo endereço de email está sendo registrado, isso é um conflito no banco de dados.
413 - Request Entity Too Large
O status code 413 é o que no diz que estamos tentando enviar algo muito maior que o esperado para o nosso servidor. Esse código de status é usado principalmente em solicitações com body muito longo ou solicitações muito pesadas. Novamente, os Serviços de armazenamento do Azure também usam essas respostas ao criar ou editar novos blobs.
Quando usá-lo: Usado principalmente quando a solicitação possui um body, nos métodos POST,PUT e PATCH. O caso de uso mais comum é o upload de imagens, se a imagem for maior do que o servidor pode ou deseja processar.
415 - Unsupported Media Type
Este também é bastante direto. Tipo de mídia não suportado é usado quando o servidor não suporta o Content-Type da solicitação recebida. Mais uma vez, as APIs de armazenamento como Azure acabam usando muito ao criar blobs
Quando usá-lo: Novamente, no caso de upload de imagens, vamos imaginar que temos um documento sendo carregado como PDF, mas aceitamos apenas JPEG, isso retornaria 415.
Essa também é uma excelente representação do motivo pelo qual não devemos usar 400 para tudo
422 - Unprocessable Entity
Este código de status é definido no RFC4918, e é a principal razão pela qual escrevi este artigo. A maioria das pessoas usa o código de status 400 quando o payload de uma solicitação está incorreta, o que significa que é uma solicitação incorreta, mas o problema não está na solicitação em si, está no payload; este é o motivo pelo qual o 400 não deve ser usado nesses casos. Em vez disso, devemos usar 422 para dizer que a solicitação é ok, o servidor entende, mas não pode processá-lo devido a uma entidade enviada incorretamente.
Quando usá-lo: Erros de validação, ponto final. Se seu payload não corresponder a um padrão de validação, digamos, o campo email não é um email válido, então essa entidade não é processável, portanto 422.
Vamos dar uma pausa
Agora chegamos ao final da seção dois! No último artigo, explicaremos outros códigos de status que não são usados ou acabaram sendo esquecidos nos pântanos da Internet!
Não deixe de acompanhar mais do meu conteúdo no meu blog e se inscreva na newsletter para receber notícias semanais!
Viu algum erro, tem alguma sugestão ou crítica? Deixe seu comentário aqui! Ou então me mande uma mensagem em minhas redes sociais! Todo feedback é bem vindo :D
Top comments (2)
Excelente post Lucas! Fiquei com uma dúvida em relação ao cód 206, que vc disse que no caso da última página, deveria retornar o 200, porém e se a requisição já for direto para a última página, sem requisitar as demais? Não configuraria uma resposta parcial em relação ao todo? E de toda forma, mesmo requisitando todas as páginas, uma por uma, cada uma das respostas seria uma parcial.
Muito interessante, essa pode ser uma das interpretações também! Eu costumo mandar 200 somente pelo fato de que se a pessoa passar da última página eu mando um código de range exceeded então eu posso saber sem ter que fazer uma próxima request. Mas você pode tentar também incluir um novo campo ou header para dizer que esta é a última página