📚 Pré-requisitos Teóricos: este projeto aplica conceitos ensinados em Módulo 07: Backend e APIs. Recomendado revisar antes de começar.

🌐 Arquitetura de APIs RESTful, Richardson Maturity & OpenAPI 3.0

v1.0 — Design de APIs, HATEOAS, OpenAPI 3.0 / Swagger e RFC 7807

Trilha de Especialização Pedagógica — Projeto 1 de 4

🎓 Nível Profissional Simulado: Engenheiro de Backend Júnior / Pleno. Criar uma API não é apenas responder um JSON com status 200 para tudo. Um arquiteto de backend domina os verbos HTTP semânticos (GET, POST, PUT, PATCH, DELETE), códigos de status (201, 204, 400, 404, 409, 422), paginação por cursor, contratos OpenAPI 3.0 e hipermídia HATEOAS.


🎯 Objetivo & Escopo do Projeto

Projetar e documentar uma API RESTful Corporativa de Pedidos e Catálogo no Nível 3 do Modelo de Maturidade de Richardson, com hipermídia HATEOAS, documentação interativa via OpenAPI 3.0 / Swagger, paginação eficiente e padronização de tratamento de erros no formato RFC 7807 (Problem Details).


🧑‍💼 Fase 1 — Levantamento de Requisitos

O Briefing do Cliente (Arquiteto de Integração B2B)

“Nossos parceiros comerciais precisam se integrar com nossa API de pedidos. Eles reclamam que a API antiga usava POST para tudo e devolvia status 200 mesmo quando dava erro no banco. Queremos uma API RESTful impecável: rotas plurais (/api/v1/pedidos), verbos corretos, códigos HTTP semânticos, links HATEOAS para ações seguintes (cancelar, pagar) e documentação Swagger onde o desenvolvedor possa testar no navegador.”

Requisitos Funcionais (RF) e Não-Funcionais (RNF)

ID Tipo Descrição Origem no Briefing
RF01 Funcional Expor endpoints CRUD para Pedidos e Itens com URIs no plural e versionadas (/api/v1/...). “rotas plurais e versionadas”
RF02 Funcional Utilizar códigos HTTP adequados: 201 Created no POST, 204 No Content no DELETE, 404 Not Found, etc. “códigos HTTP semânticos”
RF03 Funcional Incluir links de hipermídia HATEOAS no payload de resposta para guiar o cliente. “links HATEOAS para ações seguintes”
RF04 Funcional Padronizar erros de negócio no formato RFC 7807 (type, title, status, detail). “devolvia 200 quando dava erro”
RNF01 Não-Funcional Contrato documentado integralmente no formato OpenAPI 3.0 / Swagger. Documentação B2B
RNF02 Não-Funcional Idempotência garantida para métodos PUT e DELETE. Confiabilidade REST

📋 Fase 2 — Backlog & User Stories

ID User Story Prioridade
US01 Como integrador parceiro, quero consultar a documentação no Swagger UI e testar chamadas interativas. Alta
US02 Como cliente da API, quero receber links HATEOAS para saber quais operações posso executar no pedido. Alta

🌿 Fase 3 — Engenharia em Equipe (Git Flow & Setup)

# Branch da funcionalidade
git checkout -b feature/US01-openapi-spec

# Visualizar o contrato OpenAPI 3.0
cat api_spec.yaml

🛠️ Fase 4 — Implementação do Contrato OpenAPI & Resposta HATEOAS

Payload HATEOAS Padronizado (GET /api/v1/pedidos/101)

{
  "id": 101,
  "cliente": "Empresa ABC Ltda",
  "status": "PENDENTE_PAGAMENTO",
  "valorTotal": 4500.00,
  "_links": {
    "self": { "href": "/api/v1/pedidos/101" },
    "pagar": { "href": "/api/v1/pedidos/101/pagamentos", "method": "POST" },
    "cancelar": { "href": "/api/v1/pedidos/101/cancelar", "method": "PUT" }
  }
}


🚀 Como Executar no Laboratório

1. Abra o terminal na pasta deste projeto

No seu editor/IDE, abra a pasta deste projeto (File > Open Folder) ou navegue via terminal:

cd backend_01_rest_api_architecture

2. Execute a aplicação ou testes

# Executar comandos específicos da tecnologia:
python main.py # ou npm run dev / ./gradlew build

[!TIP] Dica para execução a partir da raiz do repositório: Se você abriu o repositório completo no VS Code, basta navegar até a pasta antes de executar: cd catalogo_projetos/backend_01_rest_api_architecture`

🧭 Decisões de Arquitetura (ADRs)


🧪 Testes de Validação & Asserções

# Validar se o contrato YAML está estritamente em conformidade com OpenAPI 3.0
npx @redocly/cli lint api_spec.yaml


🏛️ Arquitetura Visual & Engenharia do Sistema

O diagrama abaixo sintetiza a organização dos artefatos, contratos e diretrizes arquiteturais na subpasta openapi/:

Arquitetura da Aplicação

flowchart TD
    subgraph Especificacao["Especificação & Contratos"]
        E1["Contratos Formais"] --> E2["Modelagem de Domínio"]
    end
    subgraph Implementacao["Implementação & Stacks"]
        I1["Arquiteturas & Código"] --> I2["Paridade Multilinguagem"]
    end
    subgraph Padroes["Governança & Padrões"]
        P1["Living Styleguides"] --> P2["Conformidade de Design"]
    end
    subgraph Homologacao["Qualidade & Homologação"]
        Q1["Matriz de Rastreabilidade"] --> Q2["Checkpoints CP-01..05 PASS"]
    end

    Especificacao --> Implementacao
    Implementacao --> Padroes
    Padroes --> Homologacao

    style Especificacao fill:#e3f2fd,stroke:#1976d2,stroke-width:1.5px
    style Implementacao fill:#fffde7,stroke:#fbc02d,stroke-width:1.5px
    style Padroes fill:#e8f5e9,stroke:#388e3c,stroke-width:1.5px
    style Homologacao fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1.5px

🎯 Engenharia de Requisitos & Modelagem Formal

👤 User Stories (Histórias de Usuário)

ID Persona História de Usuário Critério de Aceite Prioridade
US-01 Arquiteto de APIs Desejo especificação OpenAPI 3.0 completa definindo contratos e schemas Documentação interativa com endpoints, parâmetros, corpos e status codes Alta
US-02 Desenvolvedor Backend Desejo aderência ao Modelo de Maturidade de Richardson (Níveis 1, 2 e 3) Uso semântico de verbos HTTP, recursos bem definidos e hipermídia HATEOAS Alta
US-03 Engenheiro de Integração Desejo padronização de tratamento de erros com RFC 7807 (Problem Details) Respostas de erro consistentes com type, title, status, detail e instance Alta
US-04 Especialista em Performance Desejo estratégias de paginação por cursor e cabeçalhos de cache ETag Paginação escalável para coleções volumosas e validação de cache condicional Média
US-05 Auditor de Governança Desejo validação do OpenAPI com Spectral linter garantindo regras corporativas Verificação estática de descrições, tags e conformidade de schemas de resposta Média

⚙️ Requisitos Funcionais (RF)

ID Descrição do Requisito Criticidade
RF-01 Especificação OpenAPI 3.0 formal documentando API corporativa de pedidos Alta
RF-02 Estruturação de respostas de erro aderentes ao padrão RFC 7807 Problem Details Alta
RF-03 Links HATEOAS demonstrando o Nível 3 de Richardson para transições de estado Alta
RF-04 Padrão de cabeçalhos de controle de versão (Accept Header / Path Versioning) Média
RF-05 Suíte de testes de validação de contrato e linting de especificação OpenAPI Média

🛡️ Requisitos Não-Funcionais (RNF)

ID Especificação Arquitetural Criticidade
RNF-01 Idempotência rigorosamente garantida para métodos PUT e DELETE Alta
RNF-02 Segurança com declaração de schemas de autenticação Bearer JWT e OAuth2 Alta
RNF-03 Compatibilidade com geradores automáticos de código (OpenAPI Generator) Média
RNF-04 Organização dos arquivos de especificação na subpasta openapi/ Alta
RNF-05 Documentação clara de governança e ciclo de vida de endpoints Média

🔗 Matriz de Rastreabilidade (RTM)

User Story Requisito Funcional Requisito Não-Funcional Módulo / Artefato de Código Status de Homologação
US-01 RF-01 RNF-02, RNF-04 openapi/api_spec.yaml Testado
US-02 RF-03 RNF-01, RNF-03 openapi/api_spec.yaml Testado
US-03 RF-02 RNF-01, RNF-04 openapi/api_spec.yaml Testado
US-04 RF-04 RNF-01, RNF-03 openapi/api_spec.yaml Testado
US-05 RF-05 RNF-03, RNF-05 docs/test_spectral.sh Testado

🏁 Checkpoints de Qualidade & Homologação

Checkpoint Escopo da Validação Artefato Verificado Status
CP-01 Estruturação de Contratos & Pastas openapi/ PASS ✅
CP-02 Modelagem de Domínio & Schemas Domain Schemas PASS ✅
CP-03 Paridade Técnica & Implementações Multi-stack Code PASS ✅
CP-04 Documentação Viva & Estilo Styleguide & Guides PASS ✅
CP-05 Homologação com RTM & Validações Quality Gate PASS ✅