📚 Pré-requisitos Teóricos: este projeto aplica conceitos ensinados em Módulo 07: Backend e APIs. Recomendado revisar antes de começar.
v1.0 — Design de APIs, HATEOAS, OpenAPI 3.0 / Swagger e RFC 7807
Trilha de Especialização Pedagógica — Projeto 1 de 4
- ➡️ v1 (este): Fundamentos de Backend · RESTful Design · Richardson Nível 3 · OpenAPI 3.0 · RFC 7807
- v2: Autenticação Stateless com JWT e Refresh Tokens
- v3: GraphQL Federation & Subscriptions em Tempo Real
- v4: Arquitetura de Microsserviços com API Gateway e Service Mesh
🎓 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.
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).
“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.”
| 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 |
| 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 |
# Branch da funcionalidade
git checkout -b feature/US01-openapi-spec
# Visualizar o contrato OpenAPI 3.0
cat api_spec.yaml
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" }
}
}
No seu editor/IDE, abra a pasta deste projeto (File > Open Folder) ou navegue via terminal:
cd backend_01_rest_api_architecture
# 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`
# Validar se o contrato YAML está estritamente em conformidade com OpenAPI 3.0
npx @redocly/cli lint api_spec.yaml
O diagrama abaixo sintetiza a organização dos artefatos, contratos e diretrizes arquiteturais na subpasta openapi/:
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
| 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 |
| 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 |
| 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 |
| 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 |
| 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 ✅ |