api-design

Topics in the source

• Patrones de Diseño de API
• Cuándo Activar
• Diseño de Recursos
• Estructura de URL
• Reglas de Nomenclatura
• Métodos HTTP y Códigos de Estado
• Semántica de Métodos
• Referencia de Códigos de Estado

Convenciones y buenas prácticas para diseñar APIs REST consistentes y amigables para desarrolladores. Diseñar nuevos endpoints de API Revisar contratos de API existentes Agregar paginación, filtrado u ordenamiento Implementar manejo de errores para APIs Planificar la estrategia de versionado de API Construir APIs públicas o para partners | Método | Idempotente | Seguro | Usar Para | |--------|-----------|------|---------| | GET | Sí | Sí | Recuperar recursos | | POST | No | No | Crear recursos, disparar acciones | | PUT | Sí | No | Reemplazo completo de un recurso | | PATCH | No | No | Actualización parcial de un recurso | | DELETE | Sí | No | Eliminar un recurso | PATCH puede hacerse idempotente con la implementación adecuada Pros: Fácil de implementar, soporta "saltar a página N" Contras: Lento en offsets grandes (OFFSET 100000), inconsistente con inserciones concurrentes Pros: Rendimiento consistente independientemente de la posición, estable con inserciones concurrentes Contras: No se puede saltar a una página arbitraria, el cursor es opaco | Caso de Uso | Tipo de Paginación | |----------|----------------| | Dashboards administrativos, datasets pequeños (<10K) | Offset | | Scro

This is an excerpt. Refer to the complete source and its current requirements.