Status HTTP Fantásticos e Onde Habitam #2 - Os esquecidos
Tags: rest, webdev, statuscodes, internet
Published: 2020-03-26 14:57:24

_Photo por Kristina Tripkovic no Unsplash_

No [último artigo](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik), 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](https://http.cat) e [cachorros](https://httpstatusdogs.com) para ilustrar nossos códigos \o/

# Sumário

<!-- @import "[TOC]" {cmd="toc" depthFrom=1 depthTo=6 orderedList=false} -->

<!-- code_chunk_output -->

- [Sumário](#sumário)
- [Códigos que não vemos muito, mas que deveríamos](#códigos-que-não-vemos-muito-mas-que-deveríamos)
  - [200x](#200x)
    - [202 - Accepted](#202-accepted)
    - [204 - No Content](#204-no-content)
    - [205 - Reset Content](#205-reset-content)
    - [206 - Partial Content](#206-partial-content)
  - [300x](#300x)
    - [303 - See Other](#303-see-other)
    - [304 - Not Modified](#304-not-modified)
    - [307 - Temporary Redirect](#307-temporary-redirect)
    - [308 - Permanent Redirect](#308-permanent-redirect)
  - [400x](#400x)
    - [409 - Conflict](#409-conflict)
    - [413 - Request Entity Too Large](#413-request-entity-too-large)
    - [415 - Unsupported Media Type](#415-unsupported-media-type)
    - [422 - Unprocessable Entity](#422-unprocessable-entity)
- [Vamos dar uma pausa](#vamos-dar-uma-pausa)

<!-- /code_chunk_output -->

# 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

![](https://httpstatusdogs.com/img/202.jpg)

[Este é um código de status assíncrono](https://tools.ietf.org/html/rfc7231#section-6.3.3), 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"](https://docs.microsoft.com/en-us/azure/storage/queues/storage-queues-introduction?WT.mc_id=devto-blog-ludossan) 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](https://azure.microsoft.com/services/cognitive-services/?WT.mc_id=devto-blog-ludossan) possuem APIs como esta.

### 204 - No Content

![](https://http.cat/204)

[Este](https://tools.ietf.org/html/rfc7231#section-6.3.5) é 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](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#200-ok), 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](https://tools.ietf.org/html/rfc7231#section-6.3.6) 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](https://docs.microsoft.com/aspnet/web-api/overview/getting-started-with-aspnet-web-api/build-a-single-page-application-spa-with-aspnet-web-api-and-angularjs?WT.mc_id=devto-blog-ludossan) esse código caiu no esquecimento hoje em dia, já que a última coisa que um [SPA](https://docs.microsoft.com/aspnet/web-api/overview/getting-started-with-aspnet-web-api/build-a-single-page-application-spa-with-aspnet-web-api-and-angularjs?WT.mc_id=devto-blog-ludossan) faz é atualizar a página (afinal, é um aplicativo de página única...). Mas, às vezes, estamos lidando com [casos 202](#202-accepted) 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

![](https://http.cat/206)

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](https://tools.ietf.org/html/rfc7233#section-4.1) 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](https://docs.microsoft.com/rest/api/storageservices/specifying-the-range-header-for-file-service-operations?WT.mc_id=devto-blog-ludossan) usa esse cabeçalho com frequência.

__Quando usá-lo:__ Eu gosto de usá-lo ao executar consultas do tipo `search`, por exemplo, uma consulta` GET /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:

1. O usuário faz uma request `GET /users?page=2`
2. O usuário faz uma request `GET /users` com um cabeçalho `Range: <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](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#200-ok), se o usuário tentar acessar uma página fora do intervalo, retornarei um [204](#204-no-content) (se eu não quiser causar pânico) ou um [416](#416-request-range-not-satisfiable).

## 300x

### 303 - See Other

![](https://httpstatusdogs.com/img/303.jpg)

O código de status [See Other](https://tools.ietf.org/html/rfc7231#section-6.4.4) refere-se à segunda parte de uma solicitação `POST` ou` PUT` 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](#202-accepted) 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

![](https://http.cat/304)

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](https://tools.ietf.org/html/rfc7232#section-4.1), esse status deve ser retornado quando o cliente fizer uma request com os cabeçalhos `If-Modified-Since` ou` If-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` ou` PATCH` 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

![](https://http.cat/307)

[Este código de status](https://tools.ietf.org/html/rfc7231#section-6.4.7) é praticamente o mesmo que [302](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#302-found), 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](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#302-found), mas mais rigoroso (eu o usaria sempre).

### 308 - Permanent Redirect

![](https://httpstatusdogs.com/img/308.jpg)

Este código de status é [definido no RFC7538](https://tools.ietf.org/html/rfc7538), é o mesmo caso de [307](#307-temporary-redirect), mas em vez de substituir o [302](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#302-found), ele substitui o [301](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#301-moved-permanently), todas as outras informações são exatamente as mesmas.

__Quando usá-lo:__ Os mesmos casos que [301](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#301-moved-permanently), mas mais rigoroso (eu o usaria sempre).

## 400x

### 409 - Conflict

![](https://http.cat/409)

Esse código de status pode ser visto na Internet eventualmente, mas eu gostaria que estivesse mais presente... [O código 409](https://tools.ietf.org/html/rfc7231#section-6.5.8) 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

![](https://http.cat/413)

[O status code 413](https://tools.ietf.org/html/rfc7231#section-6.5.11) é 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](https://azure.microsoft.com/free/storage/?WT.mc_id=devto-blog-ludossan) 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

![](https://http.cat/415)

Este também é bastante direto. [Tipo de mídia não suportado](https://tools.ietf.org/html/rfc7231#section-6.5.13) é usado quando o servidor não suporta o `Content-Type` da solicitação recebida. Mais uma vez, as APIs de armazenamento como [Azure](https://azure.microsoft.com/free/storage/?WT.mc_id=devto-blog-ludossan) 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](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#400-bad-request) para _tudo_

### 422 - Unprocessable Entity

![](https://httpstatusdogs.com/img/422.jpg)

Este código de status [é definido no RFC4918](https://tools.ietf.org/html/rfc4918#section-11.2), e é a principal razão pela qual escrevi este artigo. A maioria das pessoas usa o código de status [400](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#400-bad-request) 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](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#400-bad-request) 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](https://blog.lsantos.dev/?utm_source=devto&utm_medium=article&utm_campaign=http_2) e se [inscreva na newsletter](https://blog.lsantos.dev/signup?utm_source=devto&utm_medium=article&utm_campaign=http_2) 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

| [Website](https://lsantos.dev) | [GitHub](https://github.com/khaosdoctor) | [Facebook](https://fb.com/lsantos.dev) | [LinkedIn](https://linkedin.com/in/lhs-santos) | [Twitter](https://twitter.com/_staticvoid)
|---|---|---|---|---