Manual de Diseno de APIs REST
Una API REST bien disenada no es solo una coleccion de endpoints. Es un contrato entre sistemas, equipos y consumidores que debe ser claro, estable, seguro y operable.
Capitulos previstos
- Introduccion a REST
- Recursos rutas y metodos
- Codigos de estado y errores
- Paginacion filtros y ordenacion
- Versionado
- Seguridad
- Documentacion OpenAPI
- Buenas practicas
- Contratos compatibilidad y evolucion
- Observabilidad y diagnostico
- Rendimiento cache y rate limiting
- Testing de APIs REST
- Gobierno de APIs
- Proyecto final
Que significa REST
REST es un estilo arquitectonico basado en recursos, representaciones, identificadores, operaciones uniformes y comunicacion sin estado.
En la practica, una API REST suele trabajar con:
- Recursos: usuarios, pedidos, productos, facturas.
- URLs: identificadores de recursos.
- Metodos HTTP: GET, POST, PUT, PATCH, DELETE.
- Codigos de estado: 200, 201, 400, 401, 404, 409, 500.
- Representaciones: normalmente JSON.
Objetivos de una buena API
- Ser facil de entender.
- Ser consistente.
- Ser segura por defecto.
- Tener errores accionables.
- Evolucionar sin romper clientes.
- Ser observable en produccion.
- Estar documentada como contrato.
Ejemplo basico
txt
GET /orders
POST /orders
GET /orders/{orderId}
PATCH /orders/{orderId}
DELETE /orders/{orderId}REST no es solo CRUD
Muchas APIs empiezan como CRUD, pero los sistemas reales tienen acciones de negocio:
txt
POST /orders/{orderId}/confirm
POST /invoices/{invoiceId}/send
POST /subscriptions/{subscriptionId}/cancelEstas rutas pueden ser validas cuando representan transiciones claras del dominio.
