Status HTTP Fantásticos e Onde Habitam #3 - Conclusão
Tags: http, rest, internet, webdev
Published: 2020-03-27 15:27:12

_Photo por Ilya Pavlov no Unsplash_

Falamos sobre [códigos comuns de status](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik) e [outros não tão comuns](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-2-os-esquecidos-3eee), mas a lista não termina aí! Ainda precisamos falar sobre outros códigos que são ainda menos usados, mas são tão específicos que talvez nunca os chegaremos ver!

# Sumário

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

<!-- code_chunk_output -->

- [Sumário](#sumário)
- [Outros status codes](#outros-status-codes)
  - [100x](#100x)
  - [100 - Continue](#100-continue)
    - [101 - Switching Protocols](#101-switching-protocols)
  - [200x](#200x)
    - [203 - Non-Authoritative Information](#203-non-authoritative-information)
  - [300x](#300x)
    - [300 - Multiple Choices](#300-multiple-choices)
  - [400x](#400x)
    - [406 - Not Acceptable](#406-not-acceptable)
    - [407 - Proxy Authentication Required](#407-proxy-authentication-required)
    - [408 - Request Timeout](#408-request-timeout)
    - [410 - Gone](#410-gone)
    - [411 - Length Required](#411-length-required)
    - [412 - Precondition Failed](#412-precondition-failed)
    - [414 - Request-URI Too Long](#414-request-uri-too-long)
    - [416 - Request Range Not Satisfiable](#416-request-range-not-satisfiable)
    - [417 - Expectation Failed](#417-expectation-failed)
    - [418 - I'm a Teapot](#418-im-a-teapot)
    - [426 - Upgrade Required](#426-upgrade-required)
    - [428 - Precondition Required](#428-precondition-required)
    - [431 - Request Header Fields Too Large](#431-request-header-fields-too-large)
    - [451 - Unavailable For Legal Reasons](#451-unavailable-for-legal-reasons)
    - [499 - Client Closed Request](#499-client-closed-request)
  - [500x](#500x)
    - [501 - Not Implemented](#501-not-implemented)
    - [505 - HTTP Version Not Supported](#505-http-version-not-supported)
    - [511 - Network Authentication Required](#511-network-authentication-required)
- [Conclusion](#conclusion)

<!-- /code_chunk_output -->

# Outros status codes

Agora chegamos ao ponto em que ainda temos códigos de status, mas eles não são tão usados ou tão significativos para a maioria dos aplicativos, mas isso não significa que não devamos usá-los em nossas APIs, se necessário!

É importante dizer que, como a maioria das pessoas se apega aos mais comuns, há um mundo totalmente novo de códigos de status que devem ser aproveitados ao criar APIs.

## 100x

## 100 - Continue

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

Este é um código muito comum, mas não é tão usado por muitas pessoas, porque geralmente não é enviado pelo próprio cliente. Na verdade, o cliente espera que um [status code 100](https://tools.ietf.org/html/rfc7231#section-6.2.1) para continuar enviando solicitações.

__Quando usá-lo:__ Este código é usado como resposta do servidor quando os clientes enviam solicitações parciais contendo o cabeçalho `Expect: 100-continue`. Esse cabeçalho indica que a solicitação que foi enviada contém apenas os cabeçalhos para validação e, após a validação, o servidor deve retornar um código de status 100 para indicar que o cliente agora pode enviar o corpo da solicitação (nos casos em que houver um corpo). Se o cliente receber um código de status [417](#417-expectation-failed), isso indica que o servidor não pode lidar com o cabeçalho `Expect`.

### 101 - Switching Protocols

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

[Essa](https://tools.ietf.org/html/rfc7231#section-6.2.2) é uma confirmação do servidor indicando que concordou com a solicitação do cliente de mudar de protocolo em um cabeçalho [`Upgrade`](https://tools.ietf.org/html/rfc7230#section-6.7). O servidor deve responder com outro cabeçalho `Upgrade`, indicando para qual versão do protocolo ele irá mudar.

__Quando usá-lo:__ Somente no lado do servidor, pouco uso para clientes.

## 200x

### 203 - Non-Authoritative Information

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

[O código 203](https://tools.ietf.org/html/rfc7231#section-6.3.4) é um _man-in-the-middle_ autorizado, ele diz que o server que foi requisitado, que atrás de um [proxy](https://docs.microsoft.com/azure/service-fabric/service-fabric-reverseproxy-setup?WT.mc_id=devto-blog-ludossan), retornou [200](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#200-ok), mas o servidor proxy alterou o payload da request.

__Quando usá-lo:__ Ao usar [proxies](https://docs.microsoft.com/azure/service-fabric/service-fabric-reverseproxy-setup?WT.mc_id=devto-blog-ludossan), isso é geralmente respondido pelo proxy quando ele precisa injetar mais informações no corpo da request antes de retorná-la ao cliente

## 300x

### 300 - Multiple Choices

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

O código de status [_multiple choices_](https://tools.ietf.org/html/rfc7231#section-6.4.1) indica que o recurso que você está procurando pode ser encontrado em mais de uma URI ou que possui mais de uma representação. Se a request usar um método `HEAD`, o servidor deve retornar um cabeçalho `Location` indicando a localização do recurso que ele prefere utilizar. Nos casos de métodos diferentes de `HEAD`, o servidor deve enviar um payload juntamente com o código 300 contendo uma lista de todas as representações desse recurso para que o cliente possa escolher qual é o mais apropriado.

__Quando usá-lo:__ Geralmente é usado em servidores de mídia, onde você pode ter vários locais para o mesmo arquivo, como uma [CDN](https://azure.microsoft.com/services/cdn/?WT.mc_id=devto-blog-ludossan), quando você solicita um arquivo, o [API gateway](https://azure.microsoft.com/services/api-management/?WT.mc_id=devto-blog-ludossan) pode responder um status 300 e solicita que você escolha em uma lista de locais disponíveis. Vamos dar um exemplo, em um site que solicita uma imagem de uma [CDN](https://azure.microsoft.com/services/cdn/?WT.mc_id=devto-blog-ludossan), o cliente envia uma solicitação `GET` para a imagem, que é respondida com 300 e uma lista de recursos disponíveis divididos em regiões, o cliente pode escolher a região mais próxima e obter a imagem.

## 400x

### 406 - Not Acceptable

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

[O status 406](https://tools.ietf.org/html/rfc7231#section-6.5.6) é bem simples. Ele afirma que o formato solicitado no cabeçalho `Accept` pelo cliente não corresponde a um recurso disponível no mesmo formato.

__Quando usá-lo:__ Bastante comum ao usar o [ReST](https://docs.microsoft.com/azure/architecture/best-practices/api-design?WT.mc_id=devto-blog-ludossan), vamos supor que temos uma API que retorne nomes de animais, podemos obter essas informações em XML e JSON; portanto, o cliente deve especificar um cabeçalho `Accept: application/xml` ou `Accept: application/json` na solicitação, se nosso cliente especificar `Accept: image/jpeg` e retornamos 406.

### 407 - Proxy Authentication Required

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

Esse código de status [é definido no RFC7235](https://tools.ietf.org/html/rfc7235#section-3.2), em resumo, o que diz é que um proxy entre o servidor e o cliente exige que o cliente se autentique antes de continuar.

__Quando usá-lo:__ Problema clássico de infraestrutura, não se vocês, mas toda vez que vou a uma empresa wifi há um proxy que me devolve 407 para que eu possa me autenticar para usar a Internet.

### 408 - Request Timeout

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

[Pelo código 408](https://tools.ietf.org/html/rfc7231#section-6.5.7), o servidor decide fechar uma conexão aberta devido ao tempo que o cliente levou para enviar a solicitação completa. Todos os servidores estão preparados para receber e processar uma solicitação em um determinado período de tempo e, se o cliente não enviar toda a solicitação nesse período, o servidor fechará a conexão.

__Quando usá-lo:__ Geralmente, isso acontece automaticamente quando o servidor Web detecta que uma única conexão foi aberta por muito tempo, geralmente quando carregamos arquivos grandes que demoram mais do que o servidor está disposto a esperar.

### 410 - Gone

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

[Gone](https://tools.ietf.org/html/rfc7231#section-6.5.9) é um dos códigos de status HTTP mais poderosos, pois afirma explicitamente que o recurso não só não está mais disponível, mas que nunca estará disponível novamente. Ele é mais poderoso que o [404](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#404-not-found) porque ele diz aos mecanismos de pesquisa para remover esse recurso de seus índices.

__Quando usá-lo:__ Isso é usado principalmente quando excluímos um recurso, por exemplo, na maioria das vezes eu uso uma exclusão lógica para manter os dados no banco de dados, uma coluna `deleteAt` impede que eu os mostre na página e, se alguém tentar acessar esse registro diretamente, posso devolver um 410.

### 411 - Length Required

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

O [código 411](https://tools.ietf.org/html/rfc7231#section-6.5.10) é simples, o cliente esqueceu de enviar o cabeçalho `Content-Length`.

__Quando usá-lo:__ Quase não utilizado em situações comuns de aplicativos, mas pode ser usado se você estiver fazendo o upload de arquivos e quiser saber o tamanho completo do arquivo antecipadamente, para que você possa saber se o arquivo é válido ou não.

### 412 - Precondition Failed

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

[Especificado no RFC7232](https://tools.ietf.org/html/rfc7232#section-4.2), o código de status 412 será retornado apenas se o servidor suportar os headers `If-Unmodified-Since` ou `If-None- Match` e o cliente envia uma solicitação que não pode satisfazer essa condição.

__Quando usá-lo:__ Não temos muito o que falar aqui, basicamente apenas ficamos com a definição.

### 414 - Request-URI Too Long

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

[Este código de status](https://tools.ietf.org/html/rfc7231#section-6.5.12) não aparece há um tempo, já que a maioria dos servidores hoje em dia pode processar uma enorme quantidade de dados. Mas o código de status 414 diz que o URI solicitado era muito longo para o servidor processar.

__Quando usá-lo:__ Também é bastante direto, nada que possamos falar mais sobre.

### 416 - Request Range Not Satisfiable

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

Este código [é definido no RFC7233](https://tools.ietf.org/html/rfc7233#section-4.4) e declara que quando um cliente envia um cabeçalho `Range` fora do intervalo disponível, o servidor pode processar, deve ser a resposta.

__Quando usá-lo:__ Como vimos [no último artigo](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-2-os-esquecidos-3eee#206-parcial-content), o status code 416 pode ser retornado se você estiver paginando uma solicitação e o usuário solicitar uma página fora do intervalo máximo de páginas.

### 417 - Expectation Failed

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

[Este código de status](https://tools.ietf.org/html/rfc7231#section-6.5.14) é mais como uma continuação do código [406](#406-not-acceptable), mas não com tipos de mídia uma vez que afirma que o cabeçalho `Expect` enviado pelo cliente não pode ser satisfeito pelo servidor.

__Quando usá-lo:__ Um caso comum é quando nosso servidor não suporta o cabeçalho [100](#100-continue), se esse é o caso e o cliente envia `Expect: 100-continue`, retornamos 417.

### 418 - I'm a Teapot

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

Este nem está definido na RFC porque não é um código de status oficial. O 418 faz parte da [piada de 1º de abril](https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol) que criou um novo protocolo chamado _Hyper Text Coffee Pot Control Protocol_,

__Quando usá-lo:__ Apenas diversão (a menos que você seja um bule de chá)

### 426 - Upgrade Required

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

[Esse código](https://tools.ietf.org/html/rfc7231#section-6.5.15) diz que o client deve atualizar a versão TLS usada para comunicação para a versão específicada no header `Upgrade`.

__When to use it:__ Geralmente utilizado quando os servidores tem regras explicitas sobre qual tipo de protocolo de segurança utilizar, nestes casos, quando um protocolo não for aceito, ele mandará de volta um 426.

### 428 - Precondition Required

Outro código de status que aparece sem nenhum cachorro ou gato para ilustrar (triste)... Mas! O código de status 428 [é definido no RFC6585](https://tools.ietf.org/html/rfc6585#section-3), que é o documento para códigos de status HTTP adicionais. É basicamente o servidor informando ao cliente que ele requer o cabeçalho `If-Match`.

__Quando usá-lo:__ Não há muito o que dizer, a melhor coisa é seguir a definição.

### 431 - Request Header Fields Too Large

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

O código de status 431 é [também definido no RFC6585](https://tools.ietf.org/html/rfc6585#section-5) e a mensagem diz tudo. Isso acontece quando um dos cabeçalhos ou todo o conjunto de cabeçalhos é maior que o limite máximo imposto pelo servidor.

__Quando usá-lo:__ Novamente, a definição é bastante direta aqui, este é um problema de solicitação com cabeçalhos. Sendo que ele é tão específico que torna esse código de status menos utilizável em outros casos.

### 451 - Unavailable For Legal Reasons

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

Esse código de status é especial porque [possui uma RFC inteira só pra ele](https://tools.ietf.org/html/rfc7725). Novamente, tanto a mensagem quanto o código são muito claros, o recurso não está disponível devido a algum motivo legal.

__Quando usá-lo:__ Isso é mais comum em sites de download ou produtos digitais, em que um recurso pode ser rastreado até uma propriedade pertencente a alguém, essa propriedade pode ficar indisponível por uma razão legal, digamos que um livro seja carregado ilegalmente em um site, se você tentar fazer o download, receberá 451.

### 499 - Client Closed Request

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

Isso também é especial porque não é um código de status padrão introduzido pelo IETF ou W3C, mas pelo NGINX. Esse código de status é __MUITO__ específico para casos do NGINX quando o cliente fecha a conexão enquanto o servidor ainda a está processando.

__Quando usá-lo:__ Ligado ao NGINX, eu não o usaria em nenhum outro lugar.

## 500x

### 501 - Not Implemented

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

De volta às [definições originais](https://tools.ietf.org/html/rfc7231#section-6.6.2) que entram no domínio de "eu fiz besteira", temos o código de status 501, que é destinado para informar ao cliente que o método da request não foi entendido pelo servidor ou o servidor sabe disso, mas não pode completar a request.

__Quando usá-lo:__ Uso principalmente quando tenho um método que será implementado no futuro (portanto, não é um [405](https://dev.to/khaosdoctor/deixando-sua-api-rest-mais-expressiva-com-status-codes-http-1-entendendo-os-codigos-4eik#405-method-not-allowed)), no entanto, ele ainda não está implementado, o que significa que é um trabalho em andamento. Eu sei que todos vocês me julgam sobre isso, mas algumas vezes os desenvolvedores precisam colocar as coisas online rapidamente para o bem do produto, para que não tenhamos tempo para concluir alguns recursos aqui e ali, é quando o 501 é usado.

> Apesar de o 501 ser mais relacionado ao servidor, você também pode usá-lo como um problema de implementação de aplicativos, pois o client não reconhece o servidor e a API como coisas separados.

### 505 - HTTP Version Not Supported

Outro código de status sem imagem :(, mas muito importante! Esse código de status é definido [na última seção da RFC7231](https://tools.ietf.org/html/rfc7231#section-6.6.6) como sendo uma forma de avisar os clients para atualizar seu protocolo, isso é usado apenas para dizer que o servidor não suporta a versão __major__ do HTTP e, em seguida, o servidor _DEVERIA_ envia uma representação de uma mensagem informando por que a versão não é suportada e quais outras opções de protocolo que ele permite.

__Quando usá-lo:__ Quando você não aceita solicitações HTTP/1.1 ou HTTP/1.0, somente as solicitações HTTP/2.

### 511 - Network Authentication Required

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

Falamos sobre o [407](#407-proxy-authentication-required) ser o único que diz ao cliente que ele precisa se autenticar para continuar, certo? Agora, o [código 511](https://tools.ietf.org/html/rfc6585#section-6) também diz isso, mas no nível da rede. Após este código ser recebido, o servidor deve enviar um link para um recurso que permita ao usuário enviar credenciais.

__Quando usá-lo:__ Os desenvolvedores raramente o usam, pois é um código de status relacionado à rede, mas, se você pode verificar se o usuário está conectado à rede ou não, é assim que você o usa.

# Conclusion

Muito obrigado por ler esta série! Espero que tenham gostado e, se você 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

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_3) e se [inscreva na newsletter](https://blog.lsantos.dev/signup?utm_source=devto&utm_medium=article&utm_campaign=http_3) para receber notícias semanais!

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