Preparatório Caixa TI: Desenvolvimento Web e APIs para ambientes corporativos

Arquitetura cliente-servidor no desenvolvimento web corporativo

Em ambientes corporativos, aplicações web normalmente seguem o modelo cliente-servidor: o cliente (navegador, app mobile ou outro sistema) envia requisições; o servidor processa regras de negócio, acessa dados e devolve respostas. Em integrações internas, um “cliente” pode ser outro serviço (microserviço, batch, sistema legado) consumindo uma API.

Fluxo básico (visão de prova)

• Cliente monta uma requisição (URL + método + headers + corpo opcional).
• Servidor valida, autentica/autorização, executa a operação e retorna status code, headers e body (quando aplicável).
• Intermediários podem existir: balanceadores, gateways de API, proxies e caches, que influenciam headers, roteamento e segurança.

HTTP: estrutura, métodos, códigos de status, headers e cookies/sessões

Estrutura de uma requisição e resposta HTTP

Uma requisição HTTP é composta por: (1) linha inicial (método, caminho, versão), (2) headers, (3) linha em branco, (4) body (opcional). A resposta tem: (1) linha inicial (versão, status code, motivo), (2) headers, (3) linha em branco, (4) body (opcional).

GET /api/v1/clientes?pagina=1&tamanho=20 HTTP/1.1
Host: exemplo.corp
Accept: application/json
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{ "itens": [], "pagina": 1, "tamanho": 20, "total": 0 }

Métodos HTTP mais cobrados

• GET: consulta recurso. Em geral não altera estado no servidor.
• POST: cria recurso ou executa ação não idempotente (ex.: processar pagamento).
• PUT: substitui recurso por completo (ou cria em um URI conhecido, dependendo do design).
• PATCH: atualização parcial.
• DELETE: remove recurso.
• HEAD: igual ao GET, mas sem body (útil para checar metadados).
• OPTIONS: descobre capacidades do endpoint; muito associado a CORS (pré-flight).

Idempotência (conceito de prova)

Uma operação é idempotente quando executá-la uma ou várias vezes produz o mesmo efeito final no servidor. Isso é importante para tolerância a falhas e retries (repetição automática) em redes instáveis.

• GET é tipicamente idempotente (não deveria alterar estado).
• PUT é idempotente (substituir o recurso pelo mesmo conteúdo repetidas vezes mantém o mesmo estado final).
• DELETE é idempotente (deletar de novo não muda o estado final: continua “não existe”, embora possa retornar 404/204 dependendo do design).
• POST geralmente não é idempotente (enviar duas vezes pode criar dois recursos/duas transações).

Códigos de status HTTP (mapa mental)

• 1xx: informativo (raros em prova prática).
• 2xx: sucesso. Exemplos: 200 OK, 201 Created (criação), 204 No Content (sucesso sem body).
• 3xx: redirecionamento. Ex.: 301, 302, 304 Not Modified (cache).
• 4xx: erro do cliente. Ex.: 400 Bad Request (requisição inválida), 401 Unauthorized (não autenticado/sem credenciais válidas), 403 Forbidden (autenticado, mas sem permissão), 404 Not Found, 409 Conflict (conflito de estado), 422 Unprocessable Entity (validação semântica falhou, comum em APIs).
• 5xx: erro do servidor. Ex.: 500, 502, 503.

Headers essenciais e o que eles sinalizam

• Content-Type: formato do body enviado (ex.: application/json).
• Accept: formatos aceitos pelo cliente (content negotiation).
• Authorization: credenciais (ex.: Bearer token).
• Cache-Control: regras de cache (ex.: no-store para dados sensíveis).
• ETag e If-None-Match: validação de cache e controle de concorrência otimista.
• Location: em 201 Created, aponta para o URI do recurso criado.
• Set-Cookie e Cookie: gerenciamento de estado via cookies.
• Origin, Access-Control-Allow-Origin: relacionados a CORS.

Cookies e sessões (diferença prática)

Cookie é um dado armazenado no cliente e enviado ao servidor a cada requisição para o domínio/escopo. Sessão é um estado mantido no servidor (por exemplo, dados do usuário autenticado), normalmente referenciado por um identificador de sessão guardado em cookie.

• Cookie de sessão: expira ao fechar o navegador (em geral).
• Cookie persistente: tem expiração definida.
• Boas práticas: usar flags HttpOnly (reduz acesso via JavaScript), Secure (somente HTTPS) e SameSite (mitiga CSRF).

REST em APIs corporativas: princípios, recursos e boas práticas

O que é REST (nível de prova)

REST (Representational State Transfer) é um estilo arquitetural para sistemas distribuídos. Em APIs RESTful, os endpoints representam recursos (ex.: /clientes, /contas/123), e as operações são expressas por métodos HTTP. A comunicação é stateless: cada requisição deve conter as informações necessárias para ser processada (por exemplo, token de autenticação), sem depender de estado de sessão no servidor para funcionar.

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Modelagem de recursos (exemplos)

• Listar: GET /api/v1/clientes
• Detalhar: GET /api/v1/clientes/123
• Criar: POST /api/v1/clientes
• Atualizar completo: PUT /api/v1/clientes/123
• Atualizar parcial: PATCH /api/v1/clientes/123
• Excluir: DELETE /api/v1/clientes/123

Versionamento de API (por que e como)

Versionar evita quebrar consumidores quando a API muda. Formas comuns:

• Na URL: /api/v1/... (muito comum em prova e em corporações).
• Em header: Accept: application/vnd.empresa.v1+json (mais sofisticado).
• Por query: ?version=1 (menos recomendado).

Boas práticas: mudanças incompatíveis (breaking changes) exigem nova versão; mudanças compatíveis podem ser evoluções na mesma versão (ex.: adicionar campo opcional).

Paginação (conceito e padrão de resposta)

Paginação evita respostas gigantes e melhora desempenho. Dois padrões comuns:

• Offset/limit: ?pagina=1&tamanho=20 (ou ?offset=0&limit=20).
• Cursor-based: ?cursor=abc (melhor para listas grandes e dados mutáveis).

GET /api/v1/transacoes?pagina=2&tamanho=3 HTTP/1.1
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  "itens": [
    {"id": 10, "valor": 100.00},
    {"id": 11, "valor": 50.00},
    {"id": 12, "valor": 25.00}
  ],
  "pagina": 2,
  "tamanho": 3,
  "total": 100
}

Passo a passo prático: desenhar um endpoint REST com paginação e validação

• 1) Defina o recurso: por exemplo, “transações” de uma conta: /contas/{id}/transacoes.
• 2) Defina o método: GET para consulta.
• 3) Defina parâmetros: pagina e tamanho (com limites, ex.: tamanho máximo 100).
• 4) Defina respostas: 200 com lista; 400 se parâmetros inválidos; 401/403 conforme segurança.
• 5) Defina contrato: Content-Type/Accept application/json; campos obrigatórios e opcionais.
• 6) Implemente validação: rejeitar tamanho negativo, pagina 0, etc.

Autenticação e autorização em APIs: OAuth2 e JWT (nível de prova)

Autenticação x autorização

• Autenticação: comprovar quem é o usuário/sistema (identidade).
• Autorização: verificar o que pode fazer (permissões/escopos/papéis).

OAuth2 (visão conceitual)

OAuth2 é um framework de autorização muito usado para permitir que um cliente acesse recursos em nome de um usuário ou de um sistema. Elementos típicos:

• Resource Owner: usuário (dono do recurso).
• Client: aplicação que quer acessar.
• Authorization Server: emite tokens.
• Resource Server: API que valida token e entrega recurso.

Em provas, costuma aparecer a ideia de token de acesso (access token) enviado no header Authorization: Bearer.

JWT (JSON Web Token) em alto nível

JWT é um formato de token (compacto) com três partes: header.payload.signature. O payload contém “claims” (ex.: sub, exp, roles/escopos). A assinatura permite verificar integridade e autenticidade do token.

• Não confundir: JWT não é “criptografia” por si só; normalmente é assinado. Pode ser também criptografado (JWE), mas o comum é JWS (assinado).
• exp: expiração; tokens devem ter validade curta.
• Boas práticas: validar assinatura, expiração, emissor (iss) e audiência (aud).

Passo a passo prático: chamada autenticada com Bearer token

• 1) Obter token: via fluxo definido (ex.: client credentials para integração sistema-sistema).
• 2) Chamar API: incluir header Authorization: Bearer <token>.
• 3) Interpretar retorno: 401 indica token ausente/inválido/expirado; 403 indica falta de permissão (escopo/role insuficiente).

GET /api/v1/contas/123 HTTP/1.1
Accept: application/json
Authorization: Bearer eyJhbGciOi...

Segurança em aplicações web: OWASP Top 10 (conceitual) e prevenções

OWASP Top 10 (visão geral para prova)

O OWASP Top 10 é uma lista de categorias de riscos comuns em aplicações web. Em nível conceitual, o foco é reconhecer o tipo de falha e a mitigação típica.

• Broken Access Control: controle de acesso falho (ex.: usuário acessa recurso de outro). Mitigação: checagem de autorização no servidor, princípio do menor privilégio.
• Cryptographic Failures: falhas no uso de criptografia (ex.: dados sensíveis sem proteção). Mitigação: TLS, armazenamento seguro, evitar dados sensíveis desnecessários.
• Injection: injeções (SQL, comandos, etc.). Mitigação: parametrização, validação, escaping, menor privilégio.
• Insecure Design: falhas de projeto (ausência de controles). Mitigação: threat modeling, requisitos de segurança.
• Security Misconfiguration: configuração insegura (headers ausentes, debug ligado). Mitigação: hardening, revisão de configuração, automação.
• Vulnerable and Outdated Components: dependências vulneráveis. Mitigação: inventário, atualização, SCA.
• Identification and Authentication Failures: autenticação fraca. Mitigação: MFA quando aplicável, políticas de senha, proteção contra brute force, sessões seguras.
• Software and Data Integrity Failures: integridade em pipelines/atualizações. Mitigação: assinaturas, controles de CI/CD, validação de artefatos.
• Security Logging and Monitoring Failures: logs/monitoramento insuficientes. Mitigação: logs de auditoria, alertas, correlação.
• Server-Side Request Forgery (SSRF): servidor faz requisições indevidas a alvos internos. Mitigação: allowlist de destinos, bloqueio de IPs internos, validação de URL.

Validação de entrada: regra de ouro

Entrada do usuário (body, query, path, headers) deve ser tratada como não confiável. Duas ideias-chave:

• Validação por allowlist: aceitar apenas formatos esperados (ex.: regex para CPF, limites numéricos).
• Normalização e limites: tamanho máximo de campos, tipos corretos, encoding consistente.

CSRF (Cross-Site Request Forgery): o que é e como mitigar

CSRF ocorre quando um site malicioso induz o navegador do usuário autenticado a enviar uma requisição para um sistema alvo, aproveitando cookies/sessão já existentes.

• Quando é mais comum: autenticação baseada em cookie (sessão) e endpoints que alteram estado (POST/PUT/DELETE).
• Mitigações típicas: token anti-CSRF, header customizado validado, SameSite em cookies, reautenticação para ações sensíveis.

XSS (Cross-Site Scripting): o que é e como mitigar

XSS ocorre quando a aplicação permite injetar scripts que serão executados no navegador de outros usuários. Pode ser armazenado (persistente) ou refletido.

• Mitigação: escapar/encode de saída conforme contexto (HTML, atributo, JS, URL), sanitização de HTML quando necessário, Content-Security-Policy (CSP), evitar inserir conteúdo não confiável diretamente no DOM.
• Boa prática: cookies de sessão com HttpOnly reduzem impacto de roubo via XSS (não elimina XSS).

SQL Injection: o que é e como prevenir

SQL Injection ocorre quando dados de entrada são concatenados em comandos SQL, permitindo alterar a consulta. Em provas, a prevenção mais cobrada é consulta parametrizada (prepared statements).

• Prevenção: usar parâmetros (bind variables), evitar concatenação de strings, validar entrada, usar contas de banco com menor privilégio.
• Complementos: ORM ajuda, mas não é garantia; ainda é preciso parametrizar corretamente e validar.

// Exemplo conceitual (NÃO fazer):
SELECT * FROM clientes WHERE cpf = '" + cpf + "';

// Correto (conceitual):
SELECT * FROM clientes WHERE cpf = ?;

Interpretação de requisições/respostas e seleção de boas práticas (estilo prova)

Questões de interpretação (analise e responda)

1) Uma requisição retorna 401 Unauthorized. O que isso indica mais provavelmente?

• A) O usuário está autenticado, mas não tem permissão
• B) O token/credencial está ausente, inválido ou expirado
• C) O recurso não existe
• D) O servidor está fora do ar

2) Uma API retorna 403 Forbidden após enviar um token válido. Interpretação mais adequada:

• A) Falha de autenticação
• B) Falha de autorização (escopo/role insuficiente)
• C) Erro de validação de payload
• D) Redirecionamento

3) Em uma criação via POST /clientes, a resposta correta para indicar sucesso e apontar o recurso criado é:

• A) 200 OK com header Set-Cookie
• B) 201 Created com header Location
• C) 204 No Content com body JSON
• D) 304 Not Modified

4) Um endpoint GET /relatorios gera um arquivo e altera um contador de auditoria a cada chamada. Qual afirmação é mais correta?

• A) GET é sempre seguro e não altera estado
• B) GET deveria ser usado, mas não pode ter logs
• C) GET não deveria ter efeitos colaterais relevantes; se altera estado de negócio, o design deve ser revisto
• D) GET é proibido em APIs corporativas

5) Um cliente repete automaticamente uma requisição após timeout. Qual método é mais apropriado para ser repetido com segurança (idempotência)?

• A) POST
• B) PUT
• C) Qualquer um
• D) CONNECT

Seleção de boas práticas (marque a melhor opção)

6) Para mitigar CSRF em aplicações com cookies de sessão, a medida mais diretamente relacionada é:

• A) Parametrizar SQL
• B) Token anti-CSRF e SameSite em cookies
• C) Habilitar CORS para qualquer origem
• D) Retornar 201 em todas as respostas

7) Para mitigar XSS, a prática mais adequada é:

• A) Confiar na validação do navegador
• B) Escapar/encode de saída e aplicar CSP
• C) Usar apenas GET
• D) Remover autenticação

8) Para mitigar SQL Injection, a prática mais cobrada é:

• A) Concatenar strings com cuidado
• B) Usar prepared statements/queries parametrizadas
• C) Aumentar timeout do banco
• D) Desativar logs

9) Em versionamento de API, qual opção tende a ser mais simples e comum em ambientes corporativos?

• A) Versionar por fragmento (#v1)
• B) Versionar na URL (/api/v1/...)
• C) Não versionar
• D) Versionar por cor do tema

10) Em paginação, uma boa prática para evitar abuso e melhorar desempenho é:

• A) Permitir tamanho ilimitado
• B) Definir tamanho máximo e retornar metadados de paginação
• C) Retornar sempre todos os itens
• D) Usar POST para listar