ORACLE - Pular os 50 primeiros registros

Para pular os 50 primeiros registros em Oracle PL/SQL, você pode usar a cláusula `OFFSET` junto com `FETCH` (disponível a partir do Oracle 12c).  

Aqui está um exemplo prático:

sql

SELECT *

FROM minha_tabela

ORDER BY id

OFFSET 50 ROWS FETCH NEXT 100 ROWS ONLY;

```

Explicação:

- `ORDER BY id` → é **obrigatório** para garantir a ordem dos registros.

- `OFFSET 50 ROWS` → ignora os primeiros 50 registros.

- `FETCH NEXT 100 ROWS ONLY` → retorna os próximos 100 registros (pode ajustar conforme necessário).

### Se estiver em versão anterior ao Oracle 12c (sem suporte a `OFFSET`):

Você pode usar uma subquery com `ROWNUM`:

sql

SELECT *

FROM (

    SELECT t.*, ROWNUM r

    FROM (

        SELECT * FROM minha_tabela ORDER BY id

    ) t

    WHERE ROWNUM <= 150

)

WHERE r > 50;

```

- Aqui, a subquery interna ordena os dados.

- O filtro `ROWNUM <= 150` garante que só pegue até o registro 150.

- O filtro externo `r > 50` remove os primeiros 50.

ORACLE - TOP(N) é uma sintaxe específica do SQL Server (T-SQL).

 1. A Forma Moderna (Oracle 12c e superior): FETCH

Esta é a maneira mais limpa, moderna e recomendada. É a sintaxe padrão do SQL ANSI para limitar linhas.

Para obter o equivalente exato de SELECT TOP 7 ... do SQL Server, você usaria FETCH FIRST 7 ROWS ONLY.

Exemplo:

SQL

SELECT

    nome_da_coluna,

    outra_coluna

FROM

    sua_tabela

ORDER BY

    coluna_de_ordenacao DESC  -- Importante para o "top" ter sentido

FETCH FIRST 7 ROWS ONLY;

2. A Forma Clássica (Oracle 11g e anteriores): ROWNUM

Antes da versão 12c, a única maneira de limitar linhas era usando a pseudo-coluna ROWNUM. No entanto, ela tem uma particularidade importante.

ROWNUM é atribuído antes da cláusula ORDER BY. Se você quiser as 7 primeiras linhas após a ordenação (que é o que o TOP geralmente faz), você precisa usar uma subconsulta.

Exemplo (a forma correta com ORDER BY):

SQL

SELECT *

FROM (

    SELECT

        nome_da_coluna,

        outra_coluna

    FROM

        sua_tabela

    ORDER BY

        coluna_de_ordenacao DESC

)

WHERE ROWNUM <= 7;

Por que a subconsulta é necessária? Se você fizesse isto (forma incorreta):

SQL

-- !! Cuidado: Isto NÃO é o TOP 7 !!

SELECT

    nome_da_coluna,

    outra_coluna

FROM

    sua_tabela

WHERE

    ROWNUM <= 7

ORDER BY

    coluna_de_ordenacao DESC;

O Oracle pegaria as primeiras 7 linhas que ele encontrar (em ordem aleatória de armazenamento), e depois as ordenaria. Você não obteria o "top 7" real.

Bônus: Equivalente ao TOP 7 WITH TIES

Se você precisar do equivalente ao TOP 7 WITH TIES do SQL Server (que inclui todas as linhas que empatam com a 7ª posição), a sintaxe FETCH do Oracle 12c+ também suporta isso:

SQL

SELECT

    nome_da_coluna,

    outra_coluna

FROM

    sua_tabela

ORDER BY

    coluna_de_ordenacao DESC

FETCH FIRST 7 ROWS WITH TIES;

Resumo:

Se você usa Oracle 12c ou mais recente: Use FETCH FIRST 7 ROWS ONLY.

Se você usa Oracle 11g ou mais antigo: Use a subconsulta com WHERE ROWNUM <= 7.

DMSII

 DMSII é a sigla para **Data Management System II**, um sistema de gerenciamento de banco de dados (SGBD) que foi desenvolvido pela Burroughs Corporation em 1972. Ele é um dos SGBDs mais antigos, e historicamente competiu com sistemas como o IMS da IBM.

O DMSII foi originalmente baseado no **modelo de rede** para organização de dados, que era um dos modelos mais populares antes do surgimento e popularização dos bancos de dados relacionais. Em um banco de dados de rede, os dados são estruturados como um grafo, permitindo que cada "registro filho" tenha vários "registros pai", o que pode ser mais complexo do que o modelo hierárquico, mas mais flexível.

Atualmente, o DMSII ainda é usado em alguns sistemas de grande porte (mainframes) da **Unisys** (empresa que surgiu da fusão da Burroughs e Sperry). Ele é parte integrante da arquitetura **ClearPath MCP** da Unisys, que é usada em várias aplicações críticas de negócios que precisam de alta disponibilidade e desempenho.

Em resumo, o DMSII é um SGBD "legado" com uma longa história, conhecido por sua robustez e uso em ambientes de mainframe, mesmo que a maioria dos bancos de dados modernos usem o modelo relacional ou NoSQL.

O que é Git no Visual Studio?

 

O que é Git no Visual Studio?

O Git é um sistema de controle de versão distribuído que permite a você e sua equipe rastrear mudanças no código, colaborar em projetos e gerenciar diferentes versões de um software. O Visual Studio integra ferramentas Git diretamente em sua interface, facilitando o uso dessas funcionalidades sem sair do ambiente de desenvolvimento.

---

1. Buscar (Fetch)

Quando você "Busca" (ou "Fetch") no Visual Studio, você está baixando as últimas mudanças do repositório remoto (online, como GitHub, Azure DevOps, GitLab, etc.) para o seu repositório local.

• O que ele faz: Ele apenas baixa as informações sobre as novas alterações (commits) e ramificações. Ele não mescla essas mudanças com o seu código local e nem modifica seus arquivos de trabalho.

• Quando usar: Use "Buscar" para ver o que há de novo no repositório remoto sem afetar seu trabalho atual. É uma boa prática fazer um "Fetch" regularmente para se manter atualizado sobre o progresso da equipe.

---

2. Efetuar Pull (Pull)

"Efetuar Pull" (ou "Pull") é uma combinação de "Buscar" e "Mesclar" (Merge). Ele baixa as últimas alterações do repositório remoto e tenta integrá-las ao seu código local.

• O que ele faz:

  1. Busca: Baixa as novas mudanças do repositório remoto.

  2. Mescla (Merge): Tenta aplicar essas mudanças à sua branch local atual.

• Quando usar: Use "Efetuar Pull" quando você quer atualizar seu projeto local com as últimas mudanças da equipe e continuar trabalhando a partir daí. Fique atento, pois se houver conflitos entre as mudanças remotas e suas mudanças locais, o Git irá sinalizá-los para você resolver.

---

3. Efetuar Push (Push)

"Efetuar Push" (ou "Push") é o oposto de "Pull". Ele envia suas alterações (commits) do seu repositório local para o repositório remoto, tornando-as visíveis para o resto da equipe.

• O que ele faz: Envia todos os seus commits locais que ainda não estão no repositório remoto para a branch correspondente no servidor.

• Quando usar: Use "Efetuar Push" quando você concluiu uma parte do trabalho, fez os commits necessários e quer compartilhar suas atualizações com a equipe. É crucial garantir que seu código esteja em um estado funcional antes de fazer um push.

---

4. Sincronizar (Sync)

A opção "Sincronizar" no Visual Studio é uma funcionalidade que combina "Pull" e "Push" para manter seu repositório local e remoto em sincronia.

• O que ele faz:

  1. Pull (se necessário): Primeiro, ele tenta fazer um "Pull" para baixar as últimas alterações do repositório remoto.

  2. Push (se necessário): Em seguida, ele tenta fazer um "Push" para enviar seus commits locais para o repositório remoto.

• Quando usar: "Sincronizar" é útil quando você quer garantir que seu repositório local esteja totalmente atualizado com o remoto e que suas alterações locais foram enviadas. No entanto, muitos desenvolvedores preferem usar "Pull" e "Push" separadamente para ter mais controle sobre o processo e lidar com conflitos de forma mais granular.

---

RESUMO:

🔄 Buscar (Fetch)

• O que faz:
  Verifica se há atualizações no repositório remoto (como no GitHub), mas não traz as mudanças para o seu código local.

• Exemplo prático:
  Se outra pessoa fez um commit no repositório remoto, o "Buscar" apenas avisa que há novas alterações – sem misturá-las ainda com seu código local.

---

⬇️ Efetuar Pull (Pull)

• O que faz:
  Traz as mudanças do repositório remoto para seu repositório local e atualiza sua branch atual.

• É equivalente a: git fetch + git merge

• Exemplo prático:
  Você fez "Pull" e agora o seu código local está atualizado com tudo o que foi alterado no repositório remoto por outros colaboradores.

---

⬆️ Efetuar Push (Push)

• O que faz:
  Envia seus commits locais para o repositório remoto.

• Exemplo prático:
  Você terminou de trabalhar em uma funcionalidade, fez commit das mudanças localmente e agora usa "Push" para subir isso para o GitHub (ou outro servidor Git).

---

🔁 Sincronizar (Sync)

• O que faz:
  Executa Pull + Push ao mesmo tempo:

  • Primeiro, busca e integra as mudanças do remoto (Pull).

  • Depois, envia seus commits locais (Push).

• Exemplo prático:
  Útil quando você quer garantir que está com tudo atualizado e também subir seu trabalho em um único passo.

---

Resumo rápido:

Buscar	Verifica atualizações no remoto, mas não altera seu código local
Efetuar Pull	Traz mudanças do remoto para sua branch local
Efetuar Push	Envia suas alterações locais para o repositório remoto
Sincronizar	Faz Pull e Push em sequência

Em resumo, essas operações Git no Visual Studio são a espinha dorsal da colaboração em projetos de código. Entender quando e como usar cada uma delas é essencial para um fluxo de trabalho eficiente e para evitar problemas de versionamento.

O Que é Web Forms?

Web Forms é um modelo de desenvolvimento web que faz parte do ASP.NET, a estrutura de desenvolvimento da Microsoft para a construção de aplicações web. Ele foi introduzido com o .NET Framework e foi uma das primeiras abordagens para criar sites dinâmicos usando C# (ou VB.NET).

---

A Ideia Central

A grande sacada do Web Forms era tentar trazer a experiência de desenvolvimento de aplicações desktop (como as feitas em Windows Forms) para a web. Em vez de lidar diretamente com HTML, CSS, JavaScript e o ciclo de vida HTTP de requisições e respostas, os desenvolvedores trabalhavam com controles visuais (como botões, caixas de texto, grids) que podiam ser arrastados e soltos em uma página.

Pense assim:

• Aplicações Desktop: Você arrasta um botão para um formulário, dá um clique duplo e escreve o código que será executado quando o botão for clicado.

• Web Forms: A Microsoft tentou replicar isso. Você arrastava um asp:Button para sua página .aspx, dava um clique duplo e escrevia o código C# (ou VB.NET) em um arquivo "code-behind" (.aspx.cs ou .aspx.vb) que seria executado no servidor quando o botão fosse clicado no navegador.

---

Como Funciona

1. Páginas .aspx: São arquivos de texto que contêm o HTML estático e os controles de servidor ASP.NET (elementos com o prefixo asp:).

2. Code-Behind (.aspx.cs ou .aspx.aspx.vb): Para cada página .aspx, há um arquivo de código separado onde você escreve a lógica de programação para os eventos dos controles, acesso a banco de dados, etc.

3. Controles de Servidor: São objetos que você adiciona à sua página (<asp:TextBox>, <asp:Button>, <asp:GridView>, etc.). Eles são renderizados como HTML no navegador, mas você programa a lógica deles no servidor.

4. Estado da Página (View State): Este é um conceito chave no Web Forms. Como o HTTP é "stateless" (não guarda informações de uma requisição para outra), o Web Forms usa o View State (um campo oculto na página HTML) para manter o estado dos controles entre as postbacks (envios de formulário de volta ao servidor). Isso ajudava a dar a sensação de que a página estava mantendo seu estado, como uma aplicação desktop.

5. Ciclo de Vida da Página: Uma página Web Forms tem um ciclo de vida bem definido (inicialização, carregamento, manipulação de eventos, renderização), o que ajuda o desenvolvedor a saber quando e onde colocar seu código.

6. Postbacks: Quando um usuário interage com um controle (como clicar em um botão), a página inteira é enviada de volta ao servidor (um "postback"), o código no servidor é executado e a página é renderizada novamente e enviada de volta ao navegador.

---

Vantagens do Web Forms

• Curva de Aprendizagem Suave (para desenvolvedores desktop): Para quem vinha do desenvolvimento de aplicações Windows Forms, a transição para Web Forms era relativamente intuitiva devido ao modelo de eventos e controles.

• Produtividade Rápida: Era possível criar formulários e aplicações simples rapidamente, arrastando e soltando controles.

• Abstração do HTML: O desenvolvedor não precisava se preocupar tanto com os detalhes do HTML, JavaScript e CSS, pois o ASP.NET Web Forms gerava grande parte disso.

• Rico Conjunto de Controles: Oferecia uma vasta gama de controles de servidor prontos para uso, desde caixas de texto e botões até grids de dados complexos e validadores.

---

Desvantagens do Web Forms

• HTML Gerado: O HTML gerado pelo Web Forms podia ser verboso e difícil de otimizar para SEO ou para design responsivo.

• View State Pesado: O View State, embora útil, podia inchar o tamanho da página, tornando-a mais lenta para carregar, especialmente em páginas com muitos controles ou dados.

• Controle Limitado sobre o HTML/JavaScript: Para personalizações avançadas ou para integrar frameworks JavaScript modernos, o Web Forms podia ser um desafio, pois abstraía demais a camada front-end.

• Acoplamento Forte: O modelo de postback e View State criava um acoplamento forte entre o cliente e o servidor, o que dificultava a criação de Single Page Applications (SPAs) ou APIs RESTful.

---

Onde o Web Forms se Encaixa Hoje

Embora o Web Forms ainda seja usado em muitas aplicações legadas e em algumas novas aplicações internas (onde a velocidade de desenvolvimento e a familiaridade com o modelo são prioridades), ele foi largamente substituído por abordagens mais modernas para o desenvolvimento web com .NET:

• ASP.NET MVC (Model-View-Controller): Oferece maior controle sobre o HTML e uma separação de preocupações mais clara, sendo ideal para aplicações web complexas e públicas.

• ASP.NET Core: A versão mais recente e multiplataforma do ASP.NET, que unifica MVC, Web API e outros modelos, sendo a escolha preferencial para novos desenvolvimentos.

• Blazor: Permite construir interfaces de usuário interativas da web usando C# em vez de JavaScript, executando o código C# diretamente no navegador (via WebAssembly) ou no servidor.

Em resumo, o Web Forms foi um passo importante na evolução do desenvolvimento web com .NET, tornando-o acessível a muitos desenvolvedores. No entanto, o cenário web evoluiu, e outras tecnologias do ASP.NET oferecem hoje maior flexibilidade e controle para atender às demandas de aplicações web modernas.

ASP.NET Web Forms - Obter o Caminho Completo

Entendendo o Objetivo

O principal objetivo desses exemplos de código é obter o caminho completo para um arquivo chamado "Ranking.pdf" dentro da pasta "Downloads" do usuário. 

 Opção 1: Usando Environment.GetFolderPath

string CaminhoCompleto = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.UserProfile), "Downloads", "Ranking.pdf");

Usando Environment.GetFolderPath e Path.Combine

string CaminhoCompleto = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.UserProfile), "Downloads", "Ranking.pdf");

Esta é geralmente a abordagem recomendada para construir caminhos de arquivo em C#. Veja por que e como funciona:

• Environment.GetFolderPath(Environment.SpecialFolder.UserProfile):

  • Environment é uma classe que fornece informações sobre o ambiente e a plataforma atuais.

  • GetFolderPath é um método estático que recupera o caminho para uma pasta especial do sistema.

  • Environment.SpecialFolder.UserProfile é um membro de enumeração que representa o diretório de perfil do usuário (por exemplo, C:\Users\SeuNomeDeUsuario no Windows, /home/seunomedeusuario no Linux). Esta é uma maneira confiável de obter a raiz dos arquivos pessoais do usuário.

• Path.Combine(...):

  • Path é uma classe que executa operações em instâncias string que contêm informações de caminho de arquivo ou diretório.

  • Combine é um método crucial aqui. Ele concatena inteligentemente múltiplos componentes de caminho em um único caminho. 

Opção 2: Mais direto

string CaminhoCompleto = @$"{Environment.GetFolderPath(Environment.SpecialFolder.UserProfile)}\Downloads\Ranking.pdf";

Esta opção é mais "direta" no sentido de que ela constrói a string do caminho usando interpolação de string e um string literal verbatim.

Por que "mais direto"?: Ele cria o caminho combinando as partes diretamente na string.

Desvantagem: Embora funcione bem no Windows, esta abordagem não é automaticamente compatível com outras plataformas (como Linux ou macOS) que usam barras normais (/) como separadores de caminho. Se você executar este código em um sistema Linux, ele ainda tentará usar barras invertidas, o que pode causar problemas. Por isso, a Opção 1 é geralmente preferível para código multi-plataforma.

Principais categorias de comandos SQL — DDL, DML, DCL, e TCL

Principais categorias de comandos SQL — DDL, DML, DCL, e TCL — com exemplos típicos para cada:

🔷 DDL (Data Definition Language)

Usado para definir ou modificar a estrutura do banco de dados (tabelas, índices, etc.)

Comando Função

CREATE Cria objetos no banco (ex: tabelas, views)

ALTER Altera a estrutura de um objeto

DROP Remove um objeto do banco

TRUNCATE Apaga todos os registros de uma tabela, mas mantém a estrutura

RENAME Renomeia objetos

Exemplo:

sql

CopiarEditar

CREATE TABLE clientes (

    id NUMBER PRIMARY KEY,

    nome VARCHAR2(100),

    email VARCHAR2(100)

);

🔸 DML (Data Manipulation Language)

Usado para manipular os dados das tabelas

Comando Função

INSERT Insere dados

UPDATE Atualiza dados

DELETE Apaga dados

MERGE Insere ou atualiza (upsert)

Exemplo:

sql

CopiarEditar

INSERT INTO clientes (id, nome, email)

VALUES (1, 'João Silva', 'joao@email.com');

🔐 DCL (Data Control Language)

Controla permissões e acessos

Comando Função

GRANT Concede permissões

REVOKE Remove permissões

Exemplo:

sql

CopiarEditar

GRANT SELECT, INSERT ON clientes TO usuario_app;

🔄 TCL (Transaction Control Language)

Controla transações no banco de dados

Comando Função

COMMIT Confirma as alterações

ROLLBACK Desfaz alterações não confirmadas

SAVEPOINT Marca um ponto para possível rollback parcial

Exemplo:

sql

CopiarEditar

BEGIN

   UPDATE clientes SET nome = 'Maria' WHERE id = 1;

   COMMIT;

END;

 

Criar uma propriedade com get e set utilizando ViewState e trabalhando com uma lista parametrizada

Para criar uma propriedade com get e set utilizando ViewState e trabalhando com uma lista parametrizada, você pode usar a abordagem a seguir em ASP.NET:

csharp

public List<T> MinhaLista

{

    get

    {

        return ViewState["MinhaLista"] as List<T> ?? new List<T>();

    }

    set

    {

        ViewState["MinhaLista"] = value;

    }

}

Explicação:

A propriedade é definida como MinhaLista, sendo do tipo List<T> onde T é o parâmetro genérico.

Get:

O método get retorna o valor armazenado no ViewState. Caso não exista, ele retorna uma nova lista vazia (new List<T>()) para evitar valores nulos.

Set:

O método set atribui o valor passado à propriedade ao ViewState.

Como usar:

Você pode usar essa propriedade em sua página ou controle da seguinte maneira:

csharp

// Configurar valores na lista

MinhaLista = new List<string> { "Item1", "Item2", "Item3" };

// Recuperar valores da lista

foreach (var item in MinhaLista)

{

    Console.WriteLine(item);

}

Essa abordagem permite gerenciar dados no ViewState enquanto utiliza o poder das listas parametrizadas.

Comando GitLab

Aqui estão algumas opções úteis para trabalhar com o GitLab usando o Git no terminal:

Clonar um repositório do GitLab:

git clone https://gitlab.com/usuario/nome-do-repositorio.git

Adicionar uma URL remota ao seu repositório local:

git remote add origin https://gitlab.com/usuario/nome-do-repositorio.git

Fazer commit das alterações:

git add .

git commit -m "Mensagem descritiva"

Enviar as alterações para o GitLab (branch principal):

git push origin main

Obter alterações do repositório remoto:

git pull origin main

Criar e enviar uma nova branch:

git checkout -b minha-nova-branch

git push origin minha-nova-branch

IsPostBack

Usamos a propriedade IsPostBack em páginas Web Forms do ASP.NET para determinar se a página está sendo carregada pela primeira vez ou se está sendo 

recarregada como resultado de uma interação do usuário, como um clique em um botão. Isso é útil para evitar a repetição de certas operações, como o 

preenchimento de controles (ComboBox, GridView, etc.) com dados.

Explicação do IsPostBack

Carregamento Inicial da Página:

Quando a página é carregada pela primeira vez, IsPostBack é false. Nesse caso, é comum inicializar e popular os controles da página, como uma ComboBox, com dados.

Postback (Recarregamento da Página):

Quando a página é enviada de volta ao servidor devido a uma interação do usuário (como um clique em um botão), IsPostBack é true. 

Isso significa que a página está sendo recarregada e, geralmente, não precisamos repopular os controles, pois isso já foi feito no carregamento inicial.

Longo Prazo e Termos Padrão

 Longo Prazo e Termos Padrão

 

A diferença entre suporte de Longo Prazo (Long Term Support, LTS) e termos padrão (ou suporte padrão) é importante para desenvolvedores e empresas que usam tecnologias como frameworks e ferramentas de software. Aqui estão as principais distinções:

Suporte de Longo Prazo (LTS)

Duração do Suporte: As versões LTS recebem suporte por um período estendido, geralmente 3 anos ou mais, dependendo do produto. Isso inclui atualizações de segurança, correções de bugs e, às vezes, melhorias de desempenho.

Estabilidade: As versões LTS são focadas em estabilidade e confiabilidade. Elas são recomendadas para ambientes de produção onde a mudança frequente pode ser arriscada.

Atualizações de Segurança: Durante o período LTS, a prioridade é fornecer atualizações de segurança e correções críticas.

Lançamento Menos Frequente: Novas versões LTS são lançadas com menos frequência, para garantir que sejam bem testadas e estáveis.

 

Termos Padrão (Suporte Normal ou Regular)

Duração do Suporte: As versões padrão recebem suporte por um período mais curto, normalmente 12 a 18 meses. Após esse período, os usuários são incentivados a atualizar para uma versão mais recente.

Novas Funcionalidades: Versões padrão costumam incluir as últimas funcionalidades e melhorias, sendo ideais para desenvolvimento e testes.

Riscos e Mudanças: Com novas funcionalidades, podem vir mudanças que impactam a compatibilidade e estabilidade. Por isso, essas versões são mais adequadas para ambientes de desenvolvimento ou testes.

Lançamento Mais Frequente: Novas versões padrão são lançadas mais frequentemente, permitindo que os desenvolvedores tenham acesso às últimas inovações mais rapidamente.

Resumo

LTS é ideal para ambientes de produção que necessitam de estabilidade e suporte de longo prazo com foco em segurança.

Termos Padrão são ideais para desenvolvimento e testes, proporcionando acesso às últimas funcionalidades e inovações, mas com um ciclo de vida mais curto.

 

STATUS CODE

Os status codes HTTP são códigos numéricos retornados pelo servidor para indicar o resultado da requisição HTTP. Eles são agrupados em categorias baseadas na primeira cifra do código. Aqui estão alguns dos principais status codes e seus significados:

1xx: Informacional

Esses códigos indicam que a requisição foi recebida e está sendo processada.

100 Continue: O servidor recebeu a parte inicial da requisição e o cliente deve continuar enviando o restante.

101 Switching Protocols: O servidor está mudando para um protocolo diferente, conforme solicitado pelo cliente.

2xx: Sucesso

Esses códigos indicam que a requisição foi bem-sucedida.

200 OK: A requisição foi bem-sucedida e o servidor retornou os dados solicitados.

201 Created: A requisição foi bem-sucedida e um novo recurso foi criado.

204 No Content: A requisição foi bem-sucedida, mas o servidor não retornou nenhum conteúdo.

3xx: Redirecionamento

Esses códigos indicam que o cliente deve tomar ações adicionais para concluir a requisição.

301 Moved Permanently: O recurso solicitado foi movido permanentemente para uma nova URL.

302 Found: O recurso solicitado foi encontrado em uma URL diferente temporariamente.

304 Not Modified: O recurso não foi modificado desde a última requisição.

4xx: Erro do Cliente

Esses códigos indicam que houve um problema com a requisição do cliente.

400 Bad Request: A requisição é inválida ou malformada.

401 Unauthorized: A requisição requer autenticação do usuário.

403 Forbidden: O cliente não tem permissão para acessar o recurso solicitado.

404 Not Found: O recurso solicitado não foi encontrado no servidor.

405 Method Not Allowed: O método HTTP usado na requisição não é permitido para o recurso solicitado.

5xx: Erro do Servidor

Esses códigos indicam que houve um problema no servidor ao processar a requisição.

500 Internal Server Error: Ocorreu um erro genérico no servidor.

501 Not Implemented: O servidor não possui a funcionalidade necessária para atender a requisição.

502 Bad Gateway: O servidor recebeu uma resposta inválida de outro servidor ao tentar atender a requisição.

503 Service Unavailable: O servidor está temporariamente indisponível (por exemplo, devido a manutenção ou sobrecarga).

504 Gateway Timeout: O servidor não recebeu uma resposta a tempo de outro servidor ao tentar atender a requisição.

 

Tabela Resumida dos Principais Status Codes

Código	Descrição	Categoria
100	Continue	Informacional
200	OK	Sucesso
201	Created	Sucesso
204	No Content	Sucesso
301	Moved Permanently	Redirecionamento
302	Found	Redirecionamento
304	Not Modified	Redirecionamento
400	Bad Request	Erro do Cliente
401	Unauthorized	Erro do Cliente
403	Forbidden	Erro do Cliente
404	Not Found	Erro do Cliente
405	Method Not Allowed	Erro do Cliente
500	Internal Server Error	Erro do Servidor
501	Not Implemented	Erro do Servidor
502	Bad Gateway	Erro do Servidor
503	Service Unavailable	Erro do Servidor
504	Gateway Timeout	Erro do Servidor

Conclusão

Os status codes HTTP fornecem informações cruciais sobre o resultado das requisições HTTP, ajudando a identificar e resolver problemas tanto do lado do cliente quanto do servidor. 

VERBOS HTTP

Os verbos HTTP são usados para definir ações específicas em recursos da web. Eles são uma parte fundamental do protocolo HTTP (HyperText Transfer Protocol) e são comumente usados em APIs RESTful. Aqui estão os principais verbos HTTP e suas funções:

Principais Verbos HTTP

GET:

Propósito: Recuperar dados de um servidor.

Exemplo: Obter uma lista de usuários ou detalhes de um único usuário.

Idempotência: Sim (várias requisições retornam o mesmo resultado).

Uso: GET /api/users

POST:

Propósito: Enviar dados para o servidor para criar um novo recurso.

Exemplo: Criar um novo usuário ou fazer login.

Idempotência: Não (cada requisição pode resultar em uma nova criação).

Uso: POST /api/users

PUT:

Propósito: Atualizar um recurso existente no servidor.

Exemplo: Atualizar informações de um usuário.

Idempotência: Sim (várias requisições resultam no mesmo estado).

Uso: PUT /api/users/{id}

DELETE:

Propósito: Remover um recurso do servidor.

Exemplo: Deletar um usuário.

Idempotência: Sim (várias requisições resultam no mesmo estado).

Uso: DELETE /api/users/{id}

PATCH:

Propósito: Atualizar parcialmente um recurso existente.

Exemplo: Atualizar parcialmente as informações de um usuário (apenas alguns campos).

Idempotência: Sim (várias requisições resultam no mesmo estado).

Uso: PATCH /api/users/{id}

HEAD:

Propósito: Recuperar os cabeçalhos de uma resposta sem o corpo.

Exemplo: Obter metadados sobre um recurso sem transferir o conteúdo.

Idempotência: Sim.

Uso: HEAD /api/users

OPTIONS:

Propósito: Obter informações sobre as opções de comunicação disponíveis para o recurso.

Exemplo: Descobrir quais métodos HTTP são suportados pelo servidor.

Idempotência: Sim.

Uso: OPTIONS /api/users

 

 

Tabela Resumida dos Verbos HTTP

Verbo	Propósito	Idempotência	Uso Exemplo
GET	Recuperar dados	Sim	GET /api/users
POST	Enviar dados para criar novo recurso	Não	POST /api/users
PUT	Atualizar recurso existente	Sim	PUT /api/users/{id}
DELETE	Remover recurso	Sim	DELETE /api/users/{id}
PATCH	Atualização parcial de recurso existente	Sim	PATCH /api/users/{id}
HEAD	Recuperar cabeçalhos	Sim	HEAD /api/users
OPTIONS	Obter informações sobre comunicação	Sim	OPTIONS /api/users

Conclusão

Os verbos HTTP são essenciais para a comunicação cliente-servidor em APIs RESTful. Cada verbo tem um propósito específico e comportamento que ajuda a definir como as ações devem ser realizadas nos recursos da web.