Lucas Santos

Posted on Mar 27, 2020 • Updated on Jul 31, 2020

Status HTTP Fantásticos e Onde Habitam #3 - Conclusão

#http #rest #internet #webdev

Photo por Ilya Pavlov no Unsplash

Falamos sobre códigos comuns de status e outros não tão comuns, 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

Sumário
Outros status codes
Conclusion

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

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 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, isso indica que o servidor não pode lidar com o cabeçalho Expect.

101 - Switching Protocols

Essa é uma confirmação do servidor indicando que concordou com a solicitação do cliente de mudar de protocolo em um cabeçalho Upgrade. 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

O código 203 é um man-in-the-middle autorizado, ele diz que o server que foi requisitado, que atrás de um proxy, retornou 200, mas o servidor proxy alterou o payload da request.

Quando usá-lo: Ao usar proxies, 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

O código de status multiple choices 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, quando você solicita um arquivo, o API gateway 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, 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

O status 406 é 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, 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

Esse código de status é definido no RFC7235, 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

Pelo código 408, 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

Gone é 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 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

O código 411 é 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

Especificado no RFC7232, 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

Este código de status 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

Este código é definido no RFC7233 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, 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

Este código de status é mais como uma continuação do código 406, 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, se esse é o caso e o cliente envia Expect: 100-continue, retornamos 417.

418 - I'm a Teapot

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

Esse código 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, 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

O código de status 431 é também definido no RFC6585 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

Esse código de status é especial porque possui uma RFC inteira só pra ele. 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

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

De volta às definições originais 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), 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 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

Falamos sobre o 407 ser o único que diz ao cliente que ele precisa se autenticar para continuar, certo? Agora, o código 511 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 e se inscreva na newsletter para receber notícias semanais!

Website	GitHub	Facebook	LinkedIn	Twitter

DEV Community