Perguntas e respostas sobre REST API (Guia 2026)

As APIs REST são a base da maioria das integrações da internet. Se você está se candidatando a uma vaga de backend, full stack ou engenheiro de software, provavelmente vai ter que responder perguntas sobre design de API REST, métodos HTTP e padrões de autenticação.

Neste guia, vou te mostrar as perguntas que os entrevistadores realmente fazem. Eu organizei por nível de dificuldade e tipo de função, pra você se concentrar no que é mais importante pra posição que você quer. Cada resposta inclui exemplos práticos e, quando for o caso, trechos de código que você pode adaptar.

Uma coisa pra ter em mente: os entrevistadores testam os fundamentos com muito mais frequência do que os tópicos avançados. Se você dominar o básico (métodos HTTP, códigos de status, ausência de estado), vai conseguir lidar com a maioria das entrevistas sobre API REST com confiança. Os padrões arquitetônicos sofisticados vêm depois.

Perguntas básicas sobre REST API em entrevistas

Essas perguntas testam seus conhecimentos básicos. Espere encontrá-las em quase todas as entrevistas, independentemente do nível de senioridade.

1. O que é REST e quais são suas limitações?

REST significa Representational State Transfer (Transferência de Estado Representacional). É um estilo arquitetônico para projetar aplicativos em rede, definido por Roy Fielding em sua tese de doutorado de 2000.

O REST tem seis restrições:

1. Cliente-Servidor: Separação das preocupações entre a interface do usuário e o armazenamento de dados
2. sem estado: Cada pedido tem todas as informações necessárias para ser concluído.
3. Cacheável: As respostas devem indicar se podem ser armazenadas em cache.
4. Sistema em camadas: Os componentes não conseguem ver além da sua camada imediata.
5. Interface uniforme: Maneira padronizada de interagir com recursos
6. Código sob demanda (opcional): Os servidores podem mandar código executável para os clientes.

2. Qual é a diferença entre REST e SOAP?

REST é um estilo arquitetônico; SOAP é um protocolo. O REST normalmente usa JSON sobre HTTP e aproveita os métodos HTTP padrão. O SOAP usa só XML e define seu próprio formato de mensagens com envelopes e os aders.

O SOAP ainda fazsentido para sistemas empresariais que precisam de contratos formais (WSDL) ou segurança no nível da mensagem (WS-Security).

3. O que são métodos HTTP e quando você usa cada um deles?

Os métodos HTTP definem a ação a ser executada em um recurso.

4. Qual é a diferença entre PUT e POST?

POST cria um novo recurso onde o servidor decide o URI. PUT substitui um recurso em um URI específico que o cliente escolhe.

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resource

Se você fizer um PUT para um URI que não existe, o servidor pode criá-lo. Se você fizer um PUT para um URI que já existe, vai substituir todo o recurso.

5. Qual é a diferença entre PUT e PATCH?

PUT substitui todo o recurso. O PATCH faz algumas mudanças.

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "khalid@example.com", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}

6. O que significa “sem estado” em REST?

Sem estado significa que cada solicitação precisa ter todas as informações que o servidor precisa para processá-la. O servidor não guarda nenhum contexto do cliente entre as solicitações.

Isso quer dizer que não tem sessões no servidor. Se um usuário estiver autenticado, o cliente precisa mandar as credenciais (normalmente um token) com cada solicitação.

7. O que faz uma API ser RESTful?

Uma API é realmente RESTful quando cumpre todas as restrições REST, incluindo HATEOAS (Hypermedia as the Engine of Application State). Na prática, a maioria das APIs que se autodenominam “REST” são, na verdade, “semelhantes ao REST” ou estão no nível 2 do Modelo de Maturidade de Richardson. E, sinceramente, isso é suficiente para a maioria dos casos de uso.

Níveis do Modelo de Maturidade de Richardson para APIs REST. Imagem do autor.

8. Quais são os códigos de status HTTP básicos que você precisa saber?

Você deve conhecer pelo menos esses sete códigos de status essenciais que cobrem a maioria dos cenários de API:

9. Qual é a diferença entre um recurso e um endpoint?

Um recurso é a entidade de dados (usuário, pedido, produto). Um endpoint é o caminho da URL que dá acesso a esse recurso.

Resource: User
Endpoints: GET /users, GET /users/123, POST /users

10. Quais são as melhores práticas para o design de URIs?

Use substantivos, não verbos. Mantenha os URIs em letras minúsculas com hífens para nomes com várias palavras. Use substantivos no plural para coleções.

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_items

Evite aninhamentos profundos. Em vez de /users/123/posts/456/comments/789, dá uma olhada em /comments/789 ou /comments?post_id=456.

11. O que é idempotência e quais métodos HTTP são idempotentes?

Uma operação é idempotente se, ao fazê-la várias vezes, dáo mesmo resultado que fazer uma vez só.

Um PATCH que define um valor éidempotente; um PATCH que incrementa um contador não é.

12. Qual é a diferença entre métodos seguros e idempotentes?

Os métodos seguros não alteram os recursos (GET, HEAD, OPTIONS). Os métodos idempotentes podem ser chamados várias vezes com o mesmo efeito (GET, PUT, DELETE).

Todos os métodos seguros são idempotentes, mas nem todos os métodos idempotentes são seguros. DELETE é idempotente, mas não é seguro porque altera o estado.

13. Quando você deve usar parâmetros de consulta em vez de parâmetros de caminho?

Os parâmetros de caminho identificam um recurso específico. Os parâmetros de consulta filtram, classificam ou paginam coleções.

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10

14. O que é negociação de conteúdo?

A negociação de conteúdo permite que os clientes solicitem diferentes representações de um recurso. O cliente manda um cabeçalho Accept e o servidor responde com o formato certo.

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XML

15. Qual é o objetivo do método OPTIONS?

OPTIONS mostra os métodos HTTP que um servidor suporta para uma URL específica. Os navegadores usam isso para solicitações CORS pré-voo, pra ver se as solicitações entre origens são permitidas.

Perguntas intermediárias sobre REST API em entrevistas

Essas perguntas testam a aplicação prática e a tomada de decisões. Espere encontrá-los em cargos de nível médio.

16. Qual é a diferença entre 401 e 403?

Esse é o par de códigos de status que mais confunde a galera. Já vi engenheiros experientes confundirem isso nas revisões de código.

401 Não autorizado

Significa não autenticado. O servidor não sabe quem você é. Sua resposta deve pedir pro usuário fazer login.

403 Proibido

Quer dizer, sem autorização. O servidor sabe quem você é, mas você não tem permissão. Reautenticar não vai ajudar.

Diagrama do fluxograma de decisão de erro de autenticação versus autorização. Imagem do autor.

17. Qual é a diferença entre 400 e 422?

Aqui estão alguns exemplos que mostram a diferença:

400 Pedido inválido

Isso mostra que a sintaxe está errada. O servidor não consegue analisar a solicitação (estrutura JSON inválida, cabeçalhos necessários ausentes).

422 Entidade não processável

Isso mostra que a sintaxe está certa, mas tem erros de semântica. O JSON está certo, mas os dados não passam na validação (formato de e-mail errado, senha muito curta).

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validation

18. Quando você deve usar o 409 Conflict?

Use 409 quando a solicitação entrar em conflito com o estado atual do recurso:

• Falhas de bloqueio otimista (incompatibilidade de ETag)
• Violações de restrição exclusiva (nome de usuário duplicado)
• Transições de estado inválidas (cancelamento de um pedido já enviado)

19. Como você implementa a paginação?

Duas abordagens principais:

Paginação baseada em deslocamento

Simples, mas tem problemas de desempenho com grandes conjuntos de dados.

GET /users?limit=20&offset=40

Paginação baseada em cursor

Escala melhor e evita o “desvio de página” quando os dados mudam.

GET /users?limit=20&cursor=eyJpZCI6MTIzfQ

Empresas como Stripe, GitHub e Slack usam paginação baseada em cursor para grandes conjuntos de dados.

20. Quais são as estratégias comuns de controle de versão de API?

Existem três abordagens principais, cada uma com diferentes vantagens e desvantagens:

Versões de URI

Esse é o mais comum. É bem claro e fácil de depurar.

GET /v1/users
GET /v2/users

Versões do cabeçalho

URLs mais simples, mas mais difíceis de testar nos navegadores.

GET /users
Accept-Version: v2

Versões dos parâmetros de consulta

Fácil de adicionar, mas deixa as URLs confusas.

GET /users?version=2

21. O que é um ETag e como funciona o cache?

Um ETag é um identificador de versão para um recurso. O servidor manda isso nas respostas; o cliente manda de volta nas solicitações seguintes pra ver se o recurso mudou.

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)

22. Quais métodos de autenticação são usados para APIs REST?

Os quatro métodos de autenticação mais comuns são Chaves API, Tokens Portadores, OAuth 2.0 e JWT:

23. O que é JWT e como funciona?

O JWT (JSON Web Token) tem três partes: Cabeçalho, carga útil e assinatura. Saiba mais sobre como trabalhar com JSON em Python.

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)

O servidor assina o token; os clientes enviam-no com os pedidos. O servidor verifica a assinatura sem precisar consultar o banco de dados.

24. Qual é a diferença entre RS256 e HS256?

HS256 (simétrico): O mesmo secreta, assina e verifica. Risco se vários serviços precisarem verificar tokens.

RS256 (assimétrico): A chave privada assina, a chave pública verifica. Recomendado para sistemas distribuídos onde vários serviços validam tokens.

25. O que é HATEOAS?

HATEOAS (Hypermedia as the Engine of Application State) significa que as respostas incluem links para ações e recursos relacionados.

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}

Na prática, a maioria das APIs não implementa totalmente o HATEOAS. Conheça o conceito, mas não espere implementá-lo na maioria dos trabalhos. Mesmo as grandes empresas de tecnologia raramente criam APIs totalmente compatíveis com HATEOAS.

26. Como você lida com erros de forma consistente?

Use o formato RFC 7807 Problem Details para respostas de erro consistentes:

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}

27. O que é limitação de taxa e por que é importante?

A limitação de taxa protege sua API contra abusos e garante um uso justo. Resposta comum:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0

28. Como você faz a filtragem e a classificação?

Use parâmetros de consulta com convenções claras:

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,name

Perguntas avançadas sobre API REST para entrevistas

Essas perguntas testam o raciocínio arquitetônico. Espere encontrá-los em cargos de chefia.

29. O que mudou entre o OAuth 2.0 e o OAuth 2.1?

O OAuth 2.1 junta as melhores práticas de segurança:

A principal lição: use o fluxo de código de autorização com PKCE para todos os tipos de clientes.

30. Como você implementa a idempotência para pontos finais de pagamento?

Use chaves idempotentes para tornar as solicitações POST seguras para novas tentativas:

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return result

O cliente gera um UUID e o envia junto com a solicitação. Se a mesma chave aparecer de novo, manda a resposta que tá guardada no cache.

31. Como você projetaria um limitador de taxa distribuído?

Para sistemas distribuídos, você não pode usar contadores na memória porque o tráfego é balanceado entre as instâncias. Essa é uma armadilha comum que confunde os candidatos.

Arquitetura:

1. Use o Redis para armazenamento centralizado de contadores
2. Implementar o algoritmo Token Bucket para tolerância a picos
3. Use operações atômicas (scripts Lua) para evitar condições de corrida.

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429

32. Quando você escolheria o gRPC em vez do REST?

Escolha o gRPC para:

• Comunicação interna de microsserviços (melhoria de 5 a 10 vezes na taxa de transferência)
• Requisitos de streaming em tempo real
• Mobile-to-backend com restrições de largura de banda
• Ambientes poliglotas que precisam de contratos rigorosos

Escolha REST para:

• APIs públicas com vários tipos de usuários
• Aplicativos web (suporte universal para navegadores)
• Operações CRUD simples
• Equipes que não conhecem os Protocol Buffers

33. Como você lida com operações de longa duração?

Use o padrão de solicitação assíncrona:

1. O cliente manda uma solicitação

2. O servidor devolve 202 Accepted com uma URL de status

3. O cliente fica checando o URL de status até terminar.

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}

34. O que é o padrão Saga?

O Saga lida com transações distribuídas entre microsserviços sem bloqueio. Cada serviço faz uma transação local e publica um evento. Se uma etapa falhar, as transações de compensação desfazem as etapas anteriores.

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel Order

35. Quais são as vulnerabilidades de segurança comuns do JWT?

Confusão do algoritmo O invasor muda o RS256 para HS256 e assina com a chave pública. Solução: sempre coloque os algoritmos na lista de permissões.

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])

Algoritmo "nenhum": O invasor tira a assinatura de vez. Correção: rejeitar o algoritmo “nenhum”.

Desenvolvedor backend Perguntas sobre API REST

36. O que é o problema da consulta N+1?

O problema N+1 rola quando você pega N registros e depois faz uma consulta separada para cada relação de registro.

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queries

Soluções:

Django: Use select_related() para chaves estrangeiras e prefetch_related() para relações muitos-para-muitos.

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()

SQLAlchemy: Use joinedload() ou selectinload().

37. Como você configura o pool de conexões?

O pool de conexões reutiliza as conexões do banco de dados em vez de criar novas para cada solicitação.

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)

38. Que estratégias de cache você conhece?

Existem três estratégias principais de armazenamento em cache, cada uma otimizada para diferentes padrões de acesso:

39. Como você implementa a verificação de assinatura do webhook?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

40. Quais métricas mostram se a API tá funcionando bem?

Você deve ficar de olho nessas quatro métricas importantes pra avaliar a saúde da sua API:

Perguntas sobre API REST para desenvolvedores full stack

41. Quando um navegador manda uma solicitação CORS pré-voo?

Os navegadores mandam um OPTIONS pré-voo para:

• Métodos diferentes de GET, HEAD, POST
• Cabeçalhos personalizados (Autorização, Chave X-API)
• Tipo de conteúdo diferente de form-urlencoded, multipart/form-data, text/plain

42. Como você configura o CORS de forma segura?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Nunca use caracteres curinga (*) com credenciais. Nunca permita uma origem null.

43. Onde você deve guardar os tokens no cliente?

O armazenamento de tokens envolve compromissos de segurança entre vulnerabilidades XSS e CSRF.

Melhores práticas: Armazenetokens de atualizaçãoem cookies HttpOnly com SameSite=Strict. Mantenha os tokens de acesso na memória.

44. Quando você deve usar WebSockets em vez de SSE?

A escolha depende se você precisa de comunicação bidirecional e como quer lidar com a reconexão:

Use SSE para notificações, feeds ao vivo e cotações de ações. Use WebSockets para bate-papo, jogos multijogador e edição colaborativa.

45. Como você lida com o envio de arquivos?

Para arquivos grandes, use uploads em partes com acompanhamento do progresso:

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}

Perguntas sobre API REST baseadas em cenários

46. Crie uma API REST para um sistema de reservas de hotéis

Recursos:

• /hotels - Lista e pesquisa de hotéis

• /hotels/{id}/rooms - Quartos disponíveis

• /bookings - Criar e gerenciar reservas

• /guests/{id} - Perfis dos hóspedes

Decisões importantes:

• Use a paginação com o cursor pra procurar hotéis
• Implementar bloqueio otimista para disponibilidade de salas
• Retornar 409 Conflito para tentativas de reservas duplicadas
• Use chaves idempotentes para processar pagamentos

47. Como você implementaria exclusões temporárias?

Adicione um deleted_at carimbo de data/hora em vez de remover registros:

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()

48. Como migrar da versão 1 para a versão 2 sem prejudicar os clientes?

Use o padrão Strangler Fig:

1. Implemente a v2 junto com a v1
2. Encaminhar novos recursos para a versão 2
3. Migrar gradualmente os terminais existentes
4. Comunicar a descontinuação por meio do cabeçalho Sunset
5. Remova a versão 1 após o período de migração

49. Como você criaria uma API de pesquisa com filtragem complexa?

Para uma pesquisa de produto com vários filtros:

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123

Decisões de design:

• Use o Elasticsearch para fazer buscas de texto completo (os bancos de dados relacionais têm dificuldade com correspondências aproximadas).
• Implementar pesquisa facetada para mostrar as opções de filtro disponíveis
• Mostra quantos resultados cada filtro dá, pra que os usuários saibam quantos resultados cada filtro produz.
• Armazenar combinações de pesquisa populares

50. Como você lida com o controle de versão da API em uma arquitetura de microsserviços?

Opções:

1. Controle de versão no nível do gateway: O gateway da API direciona /v1/* para os serviços antigos e /v2/* para os novos.

2. Controle de versão do nível de serviço: Cada serviço cuida da sua própria negociação de versão.

3. Contratos orientados para o consumidor: Use o Pact ou ferramentas parecidas pra garantir a compatibilidade.

Para a maioria das equipes, o controle de versão no nível do gateway oferece a separação mais clara.

51. Como você implementaria a limitação de taxa para diferentes níveis de usuários?

A solução envolve definir limites específicos para cada camada e verificá-los usando contadores Redis:

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )

Perguntas sobre API REST comportamental

52. Explique REST para alguém que não entende de tecnologia

Pense numa API REST como um garçom num restaurante. Você (o cliente) não pode entrar diretamente na cozinha. Em vez disso, você diz ao garçom o que quer do cardápio, e ele traz para você. O menu é como a documentação da API, listando o que você pode pedir. O garçom segue regras específicas: você pede algo (GET), faz um novo pedido (POST) ou devolve algo (DELETE). Se a cozinha estiver sem algum item, o garçom avisa você (404 Não encontrado) para que você não fique esperando eternamente.

Essa comparação funciona super bem nas reuniões com as partes interessadas.

53. Conte uma vez em que você otimizou uma API.

Use o método STAR:

• Situação: “Nossa API de pesquisa tinha tempos de resposta de 3 segundos durante os picos de tráfego.”
• Tarefa: Eu precisava diminuir a latência sem grandes mudanças na arquitetura.
• Ação: Adicionei cache Redis para consultas frequentes, implementei paginação baseada em cursor e adicionei índices de banco de dados.
• Resultado: O tempo de resposta caiu para 200 ms e a gente conseguiu lidar com 5 vezes mais tráfego.

54. Como você comunica mudanças importantes aos usuários da API?

1. Anuncie com antecedência: Dê um aviso prévio de pelo menos 6 a 12 meses para mudanças importantes.

2. Use o cabeçalho Sunset: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. Forneça guias de migração: Documente exatamente o que muda e como se adaptar

4. Execute as duas versões: Mantenha a versão antiga funcionando durante a transição

5. Monitorar o uso: Programe-se para ver quais clientes ainda estão usando a versão antiga

55. Que tipo de documentação você faz para APIs?

A documentação essencial inclui:

• Especificação OpenAPI/Swagger: Contrato legível por máquina
• Guia de introdução: Primeira chamada de API em menos de 5 minutos
• Guia de autenticação: Como conseguir e usar credenciais
• Referência do erro: Todos os códigos de erro possíveis e como lidar com eles
• Changelog: O que mudou em cada versão
• Documentação sobre limites de taxa: Limites por nível e como lidar com 429s

56. Quando você NÃO usaria REST?

REST nem sempre é a escolha certa. Saber quando usar alternativas ao mostra maturidade arquitetônica. Já vi equipes forçando o REST em casos de uso em que ele cria mais problemas do que resolve.

Referência rápida da API REST

Use esta seção como uma consulta rápida quando precisar verificar propriedades do método HTTP, códigos de status ou padrões comuns durante a preparação para entrevistas ou desenvolvimento no mundo real.

Comparação dos métodos HTTP

Essa tabela mostra as principais características de cada método HTTP, prate ajudar aescolher o mais adequado pro seu caso.

Referência dos códigos de status

Aqui estão os códigos de status HTTP mais usados, organizados por categoria. Concentre-se em entender quando usar cada um, em vez de decorar todas as especificações.

2xx Sucesso

• 200 OK: GET, PUT, PATCH bem-sucedidos
• 201 Criado: POST bem-sucedido (inclui cabeçalho Location)
• 204 Sem conteúdo: Exclusão bem-sucedida

Erros do cliente 4xx

• 400 Pedido inválido: Sintaxe mal formada
• 401 Não autorizado: É preciso autenticar
• 403 Proibido: Autenticado, mas não autorizado
• 404 Não encontrado: O recurso não existe.
• 409 Conflito: Conflito entre estados
• 422 Entidade não processável: Erro de validação
• 429 Muitas solicitações: Taxa limitada

Erros do servidor 5xx

• Erro interno do servidor 500: Falha genérica do servidor
• 502 Gateway inválido: Erro no servidor upstream
• 503 Serviço indisponível: Temporariamente sobrecarregado

Erros comuns a evitar

Até desenvolvedores experientes caem nessas armadilhas. Fica atento a essas armadilhas comuns ao projetar ou implementar APIs REST:

• Usando verbos em URLs (por exemplo, /getUsers em vez de /users)

• Retornando 200 OK para estados de erro, o que quebra o tratamento de erros do lado do cliente

• Confundindo 401 e 403 (Autenticação vs. Autorização)

• URLs com aninhamento excessivo além de dois níveis

• Armazenando tokens no localStorage (cria vulnerabilidades XSS)

• Ignorando a idempotência para solicitações POST

• Devolvendo mensagens de erro genéricas sem detalhes úteis

Conclusão

Eu sei que decorar definições não garante que você vai passar em todas as entrevistas técnicas. A verdade é que a engenharia no mundo real muitas vezes exige que a gente quebre as regras “rigorosas” que acabamos de falar, e os entrevistadores se importam mais com o seu raciocínio do que com a sua capacidade de recitar as especificações RFC. Para funções altamente especializadas, um conhecimento profundo da área ou experiência específica em estruturas pode ainda ser o fator decisivo.

Mas dominar esses fundamentos REST é importante, mesmo que você não se depare com essas perguntas específicas. Ele serve como um modelo para entender como a web moderna funciona. Quando te pedirem pra projetar um novo sistema ou resolver um problema de produção, entender a diferença entre um 401 e um 403 (como expliquei antes) vai te ajudar a resolver os problemas mais rápido. Você vai entender exatamente por que padronizar suas interações com a API, e não só escrever código que funcione, é o que define um engenheiro sênior.

Se você quiser se aprofundar na criação desses sistemas, confira nossa Introdução às APIs em Python .