O que são Status Code? 

Na era da conectividade digital, a comunicação entre clientes e servidores é essencial para o funcionamento de sistemas e aplicações na internet. Essa troca de dados é realizada por meio do protocolo HTTP, que garante a troca de informações entre as partes envolvidas.  

Em cada requisição feita por um cliente, o servidor responde com um código numérico conhecido como Status Code, que tem como objetivo informar se a operação foi realizada com sucesso ou se encontrou algum erro. Esses códigos são fundamentais para desenvolvedores e administradores de sistemas, pois fornecem informações claras sobre o estado das requisições, ajudando a identificar problemas e manter a fluidez das operações.  

Neste texto, iremos conhecer as diferentes categorias de Status Code e seus principais exemplos, detalhando a função de cada um na comunicação entre cliente e servidor. 

1 – Entendendo o que é um Status Code 

A internet é baseada na troca constante de dados entre clientes e servidores. Nos dias atuais, praticamente, todos os sistemas e aplicações que usamos estão conectados à internet e comunicam-se com serviços remotos localizados em servidores web. Essa comunicação ocorre através do protocolo HTTP e é nesse cenário que surgem os Status Code. 

Os Status Code, ou códigos de  status HTTP, são códigos numéricos retornados por servidores web em resposta para cada requisição feita pelos usuários (ou clientes). Esses códigos indicam se uma solicitação HTTP foi bem-sucedida ou não.  

Os códigos são compostos por três dígitos: 

– O primeiro dígito varia de 1 a 5 e indica o tipo de status; 

– O segundo e terceiro dígitos referem-se aos status contemplados no intervalo do primeiro dígito; 

Os Status Code são divididos em cinco categorias principais, as quais representam classes de respostas do servidor, organizadas da seguinte forma: 

Código Tipo Explicação 
100 – 199 Respostas informativas (Informal) Requisição em processamento pelo servidor 
200 – 299 Respostas bem-sucedidas (Success) Requisição processada com sucesso pelo servidor 
300 – 399 Mensagens de redirecionamento (Redirection) Requisição precisa ser redirecionada para ser concluída 
400 – 499 Respostas de erro do cliente (Client Error) Requisição não pode ser concluída ou possui erro de sintaxe 
500 – 599 Respostas de erro do servidor (Server Error) Requisição não pode ser concluída por falha no lado do servidor 

2 – Lista de Status Code 

Abaixo serão listados os principais Status Code retornados em requisições HTTP: 

Respostas informativas 

100 – Continue: indica ao cliente que o cabeçalho (header) da requisição foi recebido e ele deve continuar a requisição enviando o corpo (body) ou ignorar a resposta se a requisição já estiver concluída. Esse status é útil para determinar se o servidor está disposto a aceitar a requisição antes que o seu corpo (body) seja enviado, tornando o processo mais eficiente. 

101 – Switching Protocols: o servidor está mudando os protocolos conforme solicitado pelo cliente como, por exemplo, mudar para uma versão mais recente do HTTP. 

102 – Processing: este código indica que o servidor recebeu e está processando a solicitação, mas ainda não tem uma resposta pronta. 

103 – Early Hints: indica que o cliente receberá alguns campos de cabeçalho de solicitação antes da mensagem HTTP final, com instruções para que o agente de usuário pré-carregue recursos enquanto aguarda a conclusão do processo.  

Respostas bem-sucedidas 

200 – OK: a requisição foi bem-sucedida e o servidor retornou a resposta esperada. 

201 – Created: requisição bem-sucedida e um novo recurso foi criado como resultado. Geralmente, retornado em métodos PUT ou POST. 

202 – Accepted: indica que a solicitação foi recebida pelo servidor, mas não pode ser atendida. Esse retorno ocorre nos casos em que outro processo ou servidor lida com a requisição e para processamento em lote. É um retorno sem compromisso, pois não é possível enviar, posteriormente, uma resposta HHTP assíncrona indicando o resultado da solicitação.  

204 – No Content: requisição bem-sucedida, mas o servidor não retornou nenhum conteúdo. Nesse caso, não há corpo no retorno, mas os cabeçalhos podem ter alguma utilidade. 

206 – Partial Content: esse código é retornado quando o cabeçalho Range é enviado pelo cliente solicitando apenas parte de um recurso. É útil nos casos em que é necessário fazer um download fracionado de um ou mais recursos. 

Mensagens de redirecionamento 

300 – Multiple Choices: esse status indica que existe mais de uma possível resposta para a requisição, cabendo ao agente do usuário escolher entre elas.  

301 – Moved Permanently: indica que o recurso solicitado foi movido permanentemente para uma nova URL. Geralmente, retorna a nova URL no cabeçalho da resposta no item Location. 

302 Found: indica que o recurso solicitado foi alocado, temporariamente, em uma URL diferente. 

Respostas de erro do cliente 

400 – Bad Request: a requisição não pode ser processada devido a algum erro no cliente. Pode ser causado por uma sintaxe incorreta, cookies inválidos ou cache DNS não sincronizado. 

401 – Unauthorized: a requisição precisa de autenticação para ser completada. Ocorre quando o cliente deve se autenticar para obter a resposta solicitada e não realiza essa etapa corretamente. 

403 – Forbidden: o servidor entendeu a solicitação, mas não pode autorizá-la. Semelhante ao status 401, este indica uma recusa na autorização da requisição mesmo com as credenciais válidas. Geralmente, a causa desse status está relacionada com limitações de permissão do usuário como, por exemplo, tentar acessar um recurso de edição com uma permissão de visualização. 

404 – Not Found: indica que a requisição falhou porque o servidor não conseguiu localizar o recurso solicitado. Esse erro está associado a URLs digitadas incorretamente, problemas de armazenamento em cache e propagação de domínio incompleta. Pode ser causado também por uma remoção, temporária ou permanente, do recurso no lado do servidor.  

405 – Method Not Allowed: indica que o método HTTP da requisição é reconhecido pelo servidor, porém, não está disponível para o recurso solicitado. 

Respostas de erro do servidor 

500 – Internal Server Error: ocorreu um erro inesperado no servidor e a requisição não pode ser atendida no momento. 

501 – Not Implemented: o método HTTP da requisição não é reconhecido pelo servidor. Esse erro é o oposto do status 405, no qual, o método é reconhecido pelo servidor, mas não está disponível para o recurso solicitado.  

502 – Bad Gateway: o servidor, ao atuar como um gateway ou proxy, recebeu uma resposta inválida do servidor upstream e não pode atender a requisição. 

503 – Service Unavailable: o servidor está indisponível no momento. Esse erro indica um problema temporário no lado do servidor, ocorrendo devido a manutenções ou sobrecargas. 

Esses são os códigos mais conhecidos e usados no dia a dia. Além deles, muitos outros códigos existem e podem ser retornados em uma requisição. Para conferir uma lista completa dos status code existentes, clique aqui para visualizar a documentação no MDN Web Docs. 

Conclusão 

Os Status Code são essenciais para monitorar e controlar a troca de informações na web, oferecendo transparência e eficiência na comunicação entre clientes e servidores. Cada código carrega consigo uma mensagem específica, indicando desde respostas informativas até erros críticos, seja do lado do cliente ou do servidor.  

Compreender esses códigos é crucial para garantir a manutenção de sistemas e aplicações, permitindo diagnósticos rápidos e correções assertivas em eventuais falhas. Embora alguns códigos sejam mais comuns no dia a dia, há uma vasta gama de status que podem ser encontrados em diferentes cenários. Assim, conhecer e entender os Status Code é vital para o sucesso na gestão e desenvolvimento de aplicações conectadas à internet. 

Espero que este artigo seja útil de alguma forma para você. Em caso de dúvidas, sugestões ou reclamações, fique à vontade para entrar em contato. 

E se você quiser aprender mais sobre programação, acesse aqui a seção que tenho dedicada ao assunto.   

O que é CRUD? 

Diariamente, quando realizamos qualquer tarefa online, como enviar mensagens, fazer compras ou acessar redes sociais, estamos interagindo com sistemas que criam, consultam, modificam e excluem dados. Para garantir que essas operações aconteçam de forma eficiente e segura, entre diferentes dispositivos e sistemas, foram estabelecidos padrões e regras ao longo do tempo. 

O modelo CRUD (Create, Read, Update, Delete) é um desses padrões amplamente adotados no desenvolvimento de sistemas. Ele define quatro operações fundamentais para a manipulação de dados em bancos de dados, tanto relacionais quanto não relacionais. Além de padronizar as operações de processamento de dados, o CRUD também fornece uma estrutura clara para o desenvolvimento de APIs REST, amplamente utilizadas na comunicação entre aplicações e banco de dados. 

Ao longo deste texto, exploraremos o conceito de CRUD em detalhes, incluindo exemplos práticos no MongoDB, e veremos como ele se relaciona com os métodos HTTP e a criação de APIs. Vamos lá? 

1 – Significado de CRUD 

CRUD é um acrônimo para as iniciais que representam as quatro operações básicas de um banco de dados: Create (Criar), Read (Ler), Update (Atualizar), Delete (Excluir).  

Compatível tanto com bancos SQL quanto NoSQL, é por meio dessas operações que sistemas e aplicações recebem e manipulam os dados dos seus usuários. Além disso, outro ponto de destaque do CRUD, é que ele é o padrão adotado em APIs REST para interação com banco de dados, sendo, portanto, amplamente utilizado e conhecido no desenvolvimento de serviços back-end.  

Cada elemento do acrônimo CRUD representa uma operação que pode ser executada em um banco de dados, sendo definidos assim: 

Create (Criar): é a operação utilizada para criar dados em uma base.  

Read (Ler): é a operação de consulta (leitura) de dados de uma base.  

Update (Atualizar): essa operação é responsável por alterar dados registrados em uma base.

Delete (Excluir): essa operação, por sua vez, é responsável por excluir dados de uma base. 

De um modo geral, toda interação com o banco de dados precisa passar por um processo de autenticação, visando garantir a segurança dos dados. A leitura é a operação mais simples de todas, pois, trata-se somente de uma consulta aos dados criados e, geralmente, não possui grandes restrições de acesso. As demais operações são mais críticas e requerem uma atenção maior. Criar, modificar ou excluir dados deve ser restrito para poucas pessoas, as quais devem estar devidamente preparadas para realizar essas ações, pois, uma operação incorreta pode gerar grandes prejuízos para os envolvidos.  

Imagine uma situação em que um usuário inexperiente configura, incorretamente, uma operação de exclusão de dados em uma base de clientes. Era para excluir um cadastro em específico, mas, a operação excluiu a base inteira de clientes. Pense nos desdobramentos que isso poderia gerar. Por isso, é muito importante ter um controle rigoroso de qual operação pode ser executada por qual usuário, evitando que pessoas inexperientes ou, até mesmo, mal-intencionadas causem danos aos dados armazenados em uma base. 

2 – Exemplo de CRUD com MongoDB 

Para facilitar o entendimento do conceito de CRUD vamos criar um exemplo simples usando o MongoDB. Todos os comandos que veremos a seguir são aplicados, diretamente, no shell do MongoDB.  

Vamos começar criando uma collection chamada “funcionarios” para receber os dados:

use funcionarios 

Agora vamos criar os primeiros dados dessa collection usando a função insertMany(): 

db.funcionarios.insertMany([ 
{ matricula: "1000", nome: "Ana Maria Silva", cargo: "Auxiliar administrativo", salario: 2500.00}, 
  { matricula: "1001", nome: "Tiago Oliveira", cargo: "Auxiliar administrativo", salario: 2500.00}, 
  { matricula: "1002", nome: "Marcos Antonio Pereira", cargo: "Analista administrativo", salario: 4000.00}, 
  { matricula: "1003", nome: "Sergio Almeida", cargo: "Gerente", salario: 7000.00} 
]) 

Sua base de dados deve ter ficado assim:

Print do banco de dados Mongo após execução da função insertMany();

Observe que, automaticamente, o MongoDB gerou identificadores (_id) para cada documento registrado. Isso é uma regra do próprio MongoDB, onde todo documento precisa ter um campo _id, que é um identificador único para aquele registro dentro da coleção.  

Após criar os dados, vamos realizar uma operação de leitura (consulta) aos dados gravados usando a função find(): 

db.funcionarios.find() 

O resulta dessa função será visto no próprio shell do MongoDB: 

Print do banco de dados Mongo após execução da função find();

Agora vamos atualizar alguns dados de um registro da base, usando a função updateOne(): 

db.funcionarios.updateOne( 
     { matricula: "1001" },  # Critério de seleção 
     { $set: { cargo: "Assistente Administrativo" , salario: 3000.00 }} # Campos a serem atualizados ) 

Com a execução da operação acima, o resultado será esse: 

Print do banco de dados Mongo após execução da função updateOne();

Por fim, vamos excluir um registro da base, usando a função deleteOne(): 

db.funcionarios.deleteOne({ matricula: "1000"}) 

A função acima, irá gerar o seguinte resultado: 

Print do banco de dados Mongo após execução da função deleteOne();

As operações CRUD são a base para manipulação dos dados em bancos de dados. De um banco de dados para outro somente o que muda são os comandos utilizados para realizar as operações.   No entanto, o conceito fundamental permanece o mesmo, seja trabalhando com bancos de dados relacionais como MySQL ou PostgreSQL, ou com bancos NoSQL como MongoDB, que exemplificamos aqui. 

3 – O CRUD e os métodos HTTP 

Embora tenhamos demonstrado exemplos simples no MongoDB, em aplicações reais, estas operações geralmente são implementadas através de APIs REST ou interfaces de usuário, proporcionando uma camada adicional de segurança e controle da informação.  

Quando falamos de APIs REST, existe uma correspondência direta entre as operações CRUD e os métodos HTTP. Os métodos HTTP, também conhecidos como verbos HTTP, são utilizados para indicar a ação desejada ao interagir com um recurso em um servidor. Cada verbo HTTP tem um propósito específico que se alinha naturalmente com uma operação CRUD, como podemos ver na tabela abaixo: 

CRUD MÉTODO HTTP 
CREATE (Criar) POST 
READ (Ler) GET 
UPDATE (Atualizar) PUT / PATCH 
DELETE (Excluir) DELETE 

Na tabela acima, é possível perceber que para cada operação CRUD existe um método HTTP correspondente. Há uma observação no caso da operação UPDATE, que têm dois métodos HTTP: o PUT e o PATCH. 

A diferença entre eles é que, o verbo PATCH é usado para atualizações parciais de recursos, enquanto o verbo PUT é usado para substituição completa de um recurso existente. 

Entender claramente essa relação entre as operações CRUD e os métodos HTTP traz diversos benefícios para o desenvolvimento e consumo de APIs. Ao utilizar os verbos HTTP apropriados, obtemos uma semântica clara, onde a intenção de cada requisição se torna imediatamente explícita para outros desenvolvedores. 

A adoção do CRUD também permite a padronização de diferentes sistemas e frameworks, facilitando a comunicação entre eles e promovendo a interoperabilidade. 

Utilizar o CRUD no desenvolvimento de suas APIs permite construir uma comunicação simples, eficaz e segura com o seu banco de dados. Além disso, sua API será composta por serviços funcionais, robustos e escaláveis, pois, ao utilizar padrões de desenvolvimento consolidados no mercado será mais fácil de mantê-la em longo prazo, bem como aplicar melhorias. 

Conclusão 

O modelo CRUD é fundamental para a organização e manipulação de dados, garantindo simplicidade e consistência nas operações. Além de ser um conceito central em bancos de dados, ele também é essencial na construção de APIs REST e outras aplicações que lidam com dados. 

Adotar esse padrão facilita a criação de serviços mais eficientes e seguros, permitindo que desenvolvedores mantenham boas práticas de design e comunicação entre sistemas. Ao entender a relação entre as operações CRUD e os métodos HTTP, é possível construir interfaces intuitivas e escaláveis, alinhadas às melhores práticas da arquitetura de software. Em um mundo onde cada vez mais dados são criados e consumidos, o domínio desse conceito se torna indispensável para quem deseja desenvolver sistemas robustos, eficientes e bem estruturados. 

Espero que este artigo seja útil de alguma forma para você. Em caso de dúvidas, sugestões ou reclamações, fique à vontade para entrar em contato. 

E se você quer aprender mais sobre programação, acesse aqui a seção que tenho dedicada ao assunto.

O que é API REST? 

As APIs são ferramentas essenciais para conectar diferentes sistemas e serviços, principalmente com o crescimento da internet e das plataformas digitais. Dentre os vários tipos de APIs que existem, a API REST é uma das mais populares.

A API REST é aquela que segue os princípios de design da arquitetura REST. Esta arquitetura se popularizou devido a sua simplicidade e flexibilidade na construção de APIS e também pela sua independência das tecnologias utilizadas, facilitando e agilizando o trabalho de desenvolvedores. 

Neste artigo, vamos explorar os conceitos básicos da arquitetura REST, suas diretrizes e vantagens. Vamos lá! 

Têm dúvidas sobre o que é uma API? Clique aqui e conheça mais sobre esse recurso de integração de sistemas. 

1 – O que é REST? 

REST significa “Representational State Transfer”, que traduzido para o nosso idioma é “Transferência de Estado Representacional”, é um estilo de arquitetura de software que define diretrizes para a construção de APIs.  

Criada no ano 2000 pelo cientista da computação norte-americano Roy Fielding, a arquitetura REST possui o objetivo de facilitar a comunicação entre diferentes serviços conectados à internet. 

Sistemas e aplicações que fazem parte do nosso dia a dia usam tecnologias completamente diferentes na sua construção e são executados em diversos tipos de dispositivos. São as APIs REST que permitem que esses sistemas e aplicações comuniquem-se entre si, simplificando todo o seu processo de integração. 

Além disso, as regras definidas pela arquitetura REST também reduzem o tempo e o custo de desenvolvimento de novas aplicações, padronizando o processo de trabalho dos desenvolvedores e facilitando a manutenção de suas APIs ao longo do tempo.  

2 – As diretrizes da arquitetura REST 

Para que a arquitetura de um API seja considerada REST, quatro diretrizes precisam ser cumpridas, as quais são: 

1. Utilização de métodos HTTP para realizar operações nos recursos da API. Os métodos HTTP informam para o servidor o que precisa ser feito naquela requisição e, geralmente, são usados quatro métodos nas operações: GET, POST, PUT e DELETE, que compõem o chamado CRUD. 

2. Uso de URLs para identificar os recursos da API. Essas URLs também são chamadas de endpoints e servem como os pontos de comunicação entre a API e os sistemas externos. 

3. Transferência de dados entre cliente e servidor possui um formato padrão. Geralmente, são adotados formatos como JSON ou XML. 

4. Ausência de estados do lado do servidor: os estados são mantidos do lado do cliente, ocorrendo portanto uma comunicação stateless com o servidor. Isto significa que, os clientes podem requisitar recursos em qualquer ordem e como as requisições não possuem estado, elas são processadas de forma isoladas de todas as outras. Assim, o servidor completa cada solicitação do cliente, independentemente, do resultado das solicitações anteriores.

3 – Vantagens das APIs REST 

As APIs REST possuem uma série de vantagens que as tornaram populares no mercado, dentre as quais destacam-se: 

– Escalabilidade: por não possuir estados do lado do servidor, a arquitetura REST diminui a carga de trabalho do lado do servidor, permitindo que as APIs sejam escaláveis ao longo do tempo e suportem uma carga de tráfego maior com boa performance. 

Flexibilidade: a arquitetura REST permite a separação total entre recursos do cliente e do servidor. Os recursos possuem independência de plataforma, linguagem e sistema operacional. Dessa forma, eventuais mudanças de plataforma ou tecnologia na aplicação do servidor não afetam a aplicação do cliente e vice-versa. A capacidade de construir camadas de funções de aplicações na API aumenta ainda mais a flexibilidade. Por exemplo, os desenvolvedores podem fazer alterações na camada de banco de dados sem reescrever a lógica dos serviços da aplicação. 

Interoperabilidade: como não existem restrições rígidas para implementar APIs REST, elas podem ser utilizadas em uma ampla variedade de plataformas e linguagens de programação, permitindo a comunicação entre sistemas e aplicações heterogêneas.  

– Manutenibilidade: Como os componentes são desacoplados e a interface é padronizada, a arquitetura REST facilita a manutenção e evolução de APIS ao longo do tempo. É possível fazer correções ou atualizações em recursos específicos do sistema sem afetar o funcionamento geral da API.  

Conclusão 

A arquitetura REST oferece uma abordagem eficiente para a criação de APIs, facilitando a integração entre diferentes sistemas e garantindo flexibilidade e escalabilidade. Embora cada projeto tenha suas particularidades, seguir as diretrizes da arquitetura REST e as boas práticas mencionadas pode ser um grande diferencial para o sucesso no desenvolvimento de suas APIs.

Com o conhecimento correto e as ferramentas adequadas, é possível criar soluções que se adaptam facilmente às necessidades do mercado, garantindo manutenibilidade e eficiência a longo prazo. 

Se você quer aprender mais sobre programação, acesse aqui a seção que tenho dedicada ao assunto.   

Espero que este artigo seja útil de alguma forma para você. Em caso de dúvidas, sugestões ou reclamações, fique à vontade para entrar em contato.