Forem: Determinado 96

Um resumo sobre tipos de Parâmetros em REST

Determinado 96 — Mon, 06 Apr 2026 03:17:47 +0000

Tipos de parâmetros

Em APIs REST existem 3 tipos principais de parâmetros:

Tipo	Onde fica	Para que serve
Path Param	URL	Identificar recurso
Query Param	URL	Filtrar / paginar / ordenar
Body	Corpo da requisição	Enviar dados

Path Parameter (req.params)

Parâmetro que vai na URL e serve para identificar um recurso específico (usuário, linha na tabela com base num id).

Exemplo:

GET /chamados/6 PUT /chamados/6 DELETE /chamados/6

Pode ter mais que um?

Sim, um por segmento da URL.

GET /usuarios/10/chamados/6

Quando usar?

Situação	Exemplo
Buscar 1 registro	`/chamados/6`
Atualizar	`/chamados/6`
Deletar	`/chamados/6`
Recurso relacionado	`/usuarios/10/chamados/6`

Query Parameter (req.query)

Parâmetro que vai depois do ? na URL e serve para filtrar ou consultar dados.

Exemplo:

GET /chamados?status=aberto GET /chamados?prioridade=alta GET /chamados?page=2&limit=10 GET /chamados?status=aberto&prioridade=alta

Quando usar?

Situação	Exemplo
Filtro	`?status=aberto`
Paginação	`?page=2`
Limite	`?limit=10`
Ordenação	`?order=prioridade`
Busca	`?search=mouse`

Body Parameter (req.body)

Dados enviados no corpo da requisição (normalmente JSON).

Usado em:

Método	Uso
POST	Criar
PUT	Atualizar
PATCH	Atualizar parcial

Body Json

{ "titulo": "Mouse quebrado", "descricao": "Meu mouse parou de funcionar", "prioridade": "ALTA" }

Body também vem de FORMS

Quando você envia um form HTML, os dados também vão no body, não na query.

Um resumo sobre Fake Delay – Protegendo contra User Enumeration

Determinado 96 — Sun, 05 Apr 2026 23:12:39 +0000

O que é Fake Delay?

Fake delay é um atraso intencional adicionado em respostas do sistema para evitar que atacantes descubram informações sensíveis apenas pelo tempo de resposta.

Problema comum: sistemas podem responder mais rápido ou mais lento dependendo do dado solicitado, permitindo que alguém deduza informações privadas (como usuários existentes, senhas ou recursos).
Solução: introduzir um tempo de resposta uniforme, mesmo quando a ação falha, garantindo que nenhuma informação seja revelada pelo tempo.
Analogia: é como ficar sempre no mesmo ritmo de atendimento, independentemente de o pedido estar correto ou errado, para que ninguém consiga adivinhar o que acontece “por trás do balcão”.

Um resumo dos motivos para utilizar os commits antes das operações de E/S.

Determinado 96 — Sun, 05 Apr 2026 22:31:08 +0000

O que são operações de E/S?

São todas as operações em que um computador envia ou recebe dados para algum lugar fora dele mesmo. Um exemplo comum em sistemas é o envio de e-mails, que envolve comunicação com servidores externos.

Por que fazer o commit antes do envio de e-mail?

Operações de E/S podem demorar ou falhar (ex.: timeout, problemas de rede). Desta forma, manter a E/S dentro de uma transação deixa o banco aberto por mais tempo, aumentando risco de:

Deadlocks.
Travamentos.
Inconsistência de dados (ex.: o e-mail é enviado, mas o commit falha).

Fazendo o commit antes da operação de E/S, garantimos que:

O banco de dados já está atualizado.
A operação de E/S não bloqueia nem compromete a transação.

Um resumo sobre JWT Token

Determinado 96 — Sun, 05 Apr 2026 22:20:27 +0000

O que é JWT Token?

JWT é um token usado para autenticação e autorização em aplicações web. Ele permite que o usuário faça login uma vez e depois apenas envie o token nas próximas requisições.

Analogia: É como se você se cadastrasse em um clube, pagasse a mensalidade e recebesse uma carteirinha; depois, basta mostrar a carteirinha para entrar sempre, sem precisar pagar ou se cadastrar novamente.

Estrutura do JWT

O JWT tem três partes: HEADER.PAYLOAD.SIGNATURE

Header: contém o tipo do token e o algoritmo.
Payload: contém os dados do usuário.
Signature: assinatura para garantir que o token não foi alterado.

Exemplo:

{
  "alg":"HS256",
  "typ":"JWT"
}
{
  "id":18,
  "tipo":"USUARIO",
  "iat":1775408838,
  "exp":1775412438
}

Como funciona o fluxo com JWT numa aplicação?

Usuário faz login.
Servidor gera o token com os dados do usuário.
Servidor envia o token para o cliente.
Cliente envia o token nas próximas requisições.
Middleware valida o token.
Middleware coloca os dados necessários em req.user.
A rota usa os dados necessários que estão em req.user.

Boas práticas com Token

Não colocar senha no token.
Não colocar dados sensíveis.
Sempre definir expiração (exp).
Usar HTTPS.
Usar Refresh Token.