Pular para o conteúdo
Skillpedia
APIs e servidores (backend)280 mil · #13

api-design

Ajuda seu agente a projetar APIs REST seguindo as melhores práticas. É útil para definir como as APIs se comunicam, como os erros são mostrados e como organizar os dados.

O que ela faz

Ajuda a projetar ou revisar APIs (interfaces de comunicação entre programas). Garante que os nomes, códigos de status e outras partes da API sejam claros e fáceis de usar.

Quando usar

  • ✓Ao criar novas conexões entre programas.
  • ✓Ao verificar se uma conexão existente está funcionando bem.
  • ✓Ao adicionar formas de organizar ou buscar informações em uma conexão.

Exemplo do que pedir para a IA

“Como devo nomear os recursos em uma API REST?”

Quer saber mais? Abra as seções abaixo.

Como usar

O jeito mais fácil: copie a mensagem abaixo e cole no Claude, ChatGPT, Cursor ou outra IA. Ela lê a skill e segue as instruções.

Link da skill

https://github.com/affaan-m/ECC/blob/main/pi/core/skills/api-design/SKILL.md

Mensagem pronta para colar

Use esta skill para me ajudar: https://github.com/affaan-m/ECC/blob/main/pi/core/skills/api-design/SKILL.md Leia o arquivo SKILL.md desse link e siga as instruções dele na minha tarefa.
Como funciona

A IA sugere nomes claros e segue regras comuns para URLs, como usar substantivos no plural. Ela também explica como usar códigos de status HTTP (como 200 para sucesso ou 404 para não encontrado) corretamente.

Instalação

Jeito mais fácil: copie o link da skill e cole no Claude, ChatGPT ou Cursor pedindo para seguir as instruções.

No terminal (Claude Code, Codex, Cursor), na pasta do projeto:

npx skills add affaan-m/ECC --skill api-design

Ou baixe só o arquivo:

curl -L https://raw.githubusercontent.com/affaan-m/ECC/main/pi/core/skills/api-design/SKILL.md -o SKILL.md
Conteúdo técnico (SKILL.md)

Tradução do texto original do autor no GitHub. Os comandos e códigos estão como no original.

Padrões de Design de API

Convenções e melhores práticas para projetar APIs REST consistentes e amigáveis para desenvolvedores.

Quando Ativar

  • Projetando novos endpoints de API
  • Revisando contratos de API existentes
  • Adicionando paginação, filtragem ou ordenação
  • Implementando tratamento de erros para APIs
  • Planejando estratégia de versionamento de API
  • Construindo APIs voltadas para o público ou parceiros

Design de Recursos

Estrutura de URL

# Resources are nouns, plural, lowercase, kebab-case
GET    /api/v1/users
GET    /api/v1/users/:id
POST   /api/v1/users
PUT    /api/v1/users/:id
PATCH  /api/v1/users/:id
DELETE /api/v1/users/:id

# Sub-resources for relationships
GET    /api/v1/users/:id/orders
POST   /api/v1/users/:id/orders

# Actions that don't map to CRUD (use verbs sparingly)
POST   /api/v1/orders/:id/cancel
POST   /api/v1/auth/login
POST   /api/v1/auth/refresh

Regras de Nomenclatura

# GOOD
/api/v1/team-members          # kebab-case for multi-word resources
/api/v1/orders?status=active  # query params for filtering
/api/v1/users/123/orders      # nested resources for ownership

# BAD
/api/v1/getUsers              # verb in URL
/api/v1/user                  # singular (use plural)
/api/v1/team_members          # snake_case in URLs
/api/v1/users/123/getOrders   # verb in nested resource

Métodos HTTP e Códigos de Status

Semântica de Métodos

Método Idempotente Seguro Usar Para
GET Sim Sim Recuperar recursos
POST Não Não Criar recursos, acionar ações
PUT Sim Não Substituição completa de um recurso
PATCH Não* Não Atualização parcial de um recurso
DELETE Sim Não Remover um recurso

*PATCH pode ser tornado idempotente com implementação adequada

Referência de Código de Status

# Success
200 OK                    — GET, PUT, PATCH (with response body)
201 Created               — POST (include Location header)
204 No Content            — DELETE, PUT (no response body)

# Client Errors
400 Bad Request           — Validation failure, malformed JSON
401 Unauthorized          — Missing or invalid authentication
403 Forbidden             — Authenticated but not authorized
404 Not Found             — Resource doesn't exist
409 Conflict              — Duplicate entry, state conflict
422 Unprocessable Entity  — Semantically invalid (valid JSON, bad data)
429 Too Many Requests     — Rate limit exceeded

# Server Errors
500 Internal Server Error — Unexpected failure (never expose details)
502 Bad Gateway           — Upstream service failed
503 Service Unavailable   — Temporary overload, include Retry-After

Erros Comuns

# BAD: 200 for everything
{ "status": 200, "success": false, "error": "Not found" }

# GOOD: Use HTTP status codes semantically
HTTP/1.1 404 Not Found
{ "error": { "code": "not_found", "message": "User not found" } }

# BAD: 500 for validation errors
# GOOD: 400 or 422 with field-level details

# BAD: 200 for created resources
# GOOD: 201 with Location header
HTTP/1.1 201 Created
Location: /api/v1/users/abc-123

Formato da Resposta

Resposta de Sucesso

{
  "data": {
    "id": "abc-123",
    "email": "alice@example.com",
    "name": "Alice",
    "created_at": "2025-01-15T10:30:00Z"
  }
}

Resposta de Coleção (com Paginação)

{
  "data": [
    { "id": "abc-123", "name": "Alice" },
    { "id": "def-456", "name": "Bob" }
  ],
  "meta": {
    "total": 142,
    "page": 1,
    "per_page": 20,
    "total_pages": 8
  },
  "links": {
    "self": "/api/v1/users?page=1&per_page=20",
    "next": "/api/v1/users?page=2&per_page=20",
    "last": "/api/v1/users?page=8&per_page=20"
  }
}

Resposta de Erro

{
  "error": {
    "code": "validation_error",
    "message": "Request validation failed",
    "details": [
      {
        "field": "email",
        "message": "Must be a valid email address",
        "code": "invalid_format"
      },
      {
        "field": "age",
        "message": "Must be between 0 and 150",
        "code": "out_of_range"
      }
    ]
  }
}

Variantes de Envelope de Resposta

// Opção A: Envelope com wrapper de dados (recomendado para APIs públicas)
interface ApiResponse<T> {
  data: T;
  meta?: PaginationMeta;
  links?: PaginationLinks;
}

interface ApiError {
  error: {
    code: string;
    message: string;
    details?: FieldError[];
  };
}

// Opção B: Resposta plana (mais simples, comum para APIs internas)
// Sucesso: apenas retorne o recurso diretamente
// Erro: retorne o objeto de erro

…
Perguntas frequentes

O que são 'padrões de design' de API?

São regras e boas práticas que ajudam a criar APIs consistentes e fáceis de usar por outros desenvolvedores.

Por que usar nomes de recursos no plural?

Usar o plural (ex: '/usuarios' em vez de '/usuario') torna mais claro que você está lidando com uma coleção de itens.

Qual a diferença entre PUT e PATCH?

PUT é usado para substituir um recurso inteiro, enquanto PATCH é para atualizar apenas partes dele.

Detalhes

Descrição original do autor

REST API design patterns including resource naming, status codes, pagination, filtering, error responses, versioning, and rate limiting for production APIs. Use when designing or reviewing REST endpoints, resource names, status codes, pagination, or versioning.

repo: affaan-m/ECC

Popularidade

Estrelas no GitHub
280 mil
Posição no ranking
#13
Licença
MIT
Atualizada em
15/10/2026

Essa skill é útil?

0

Entre para votar.

Comentários

  • …

Mais skills deste repositório

Skills parecidas