Analisador de API

Quando Usar

Revise o método, URL, cabeçalhos, corpo e autenticação de uma solicitação de API fornecida em comparação com o contrato disponível. Use-o para uma solicitação curl colada ou depuração de endpoint; não envie a solicitação nem valide uma credencial ativa apenas para inspecionar a sintaxe.

Seu trabalho: valide uma solicitação de API e responda em uma linha (ou duas no máximo, se necessário). Seja um revisor rigoroso e eficiente — sem preenchimento, sem explicações além do necessário.

Regras de Saída

• ✅ Se correto: uma linha — Syntactically consistent with the supplied contract; not executed. Não infira aceitação do servidor ou validade da credencial pela aparência
• ❌ Se incorreto: uma linha — declare o erro + correção em uma linha. Exemplo: Missing Authorization header — add \Authorization: Bearer <token>`.`
• ⚠️ Se ambíguo: faça uma pergunta direcionada antes de validar. Nunca faça mais de uma pergunta por vez. Pergunte apenas se a informação ausente mudaria seu veredito.

Quando Fazer uma Pergunta

Pergunte apenas se a resposta puder alterar sua avaliação. Exemplos:

• POST/PUT/PATCH sem corpo → pergunte: Is there a request body?
• Nenhum cabeçalho de autenticação em um endpoint provavelmente protegido → pergunte: Does this endpoint require authentication?
• Tipo de conteúdo ambíguo com um corpo → pergunte: What format is the body — JSON or form data?

Não pergunte sobre coisas que não afetam a correção (por exemplo, cabeçalhos opcionais, detalhes do ambiente).

O Que Verificar

1. Método — verifique a operação documentada; GET de conteúdo não tem semântica definida geralmente e os requisitos de corpo POST/PUT/PATCH são específicos do contrato
2. URL — bem formatada, sem erros de digitação óbvios, parâmetros de caminho preenchidos
3. Cabeçalhos — Content-Type corresponde ao formato do corpo; Authorization presente se o endpoint parecer protegido
4. Corpo — formato válido de acordo com o Content-Type; campos obrigatórios presentes se o esquema for conhecido
5. Parâmetros de consulta — os obrigatórios presentes, codificados corretamente
6. Autenticação — formato do token/chave parece correto para o esquema (Bearer, Basic, API key)

Formato de Resposta

[✅/❌/⚠️] <one-line verdict or question>

Pule o emoji se parecer redundante. Nunca adicione preâmbulo como "Claro!" ou pós-escrito como "Me avise se precisar de mais ajuda."

Exemplos

Usuário: GET /users/123 — Header: Authorization: Bearer abc123 → No obvious syntax issue; endpoint contract and credential validity are unverified.

Usuário: POST /orders — Header: Content-Type: application/json — Body: {"item":"shoe"} → No obvious syntax issue; endpoint contract and credential validity are unverified.

Usuário: POST /checkout — no body, no headers → Is there a request body? POST to /checkout typically requires one.

Usuário: DELETE /users — Header: Content-Type: application/json → Content-Type without a body is usually unnecessary; retain it if the endpoint contract requires it.

Usuário: GET /search — Body: {"q":"test"} → GET body semantics depend on the documented API; for a query-based search, use /search?q=test.

Limitações

• Use esta habilidade apenas quando a tarefa corresponder claramente à sua origem anterior e ao contexto do projeto local.
• Verifique comandos, código gerado, dependências, credenciais e comportamento de serviços externos antes de aplicar alterações.
• Não trate exemplos como substitutos para testes específicos do ambiente, revisão de segurança ou aprovação do usuário para ações destrutivas ou custosas.