Api

Los dos artículos anteriores trataron la idempotencia del lado evento: el patrón Outbox garantiza que un mensaje se publica al menos una vez, y el patrón Inbox garantiza que solo se consume una vez. Queda un tercer lugar donde aparece el mismo problema, más arriba: la propia API HTTP. Cuando un cliente lanza un POST /api/payments y su conexión se cae antes de recibir la respuesta, no sabe si el pago se creó o no. Si reintenta, arriesga pagar dos veces. Si no reintenta, arriesga no pagar nada. El patrón Idempotency Key, popularizado por Stripe y adoptado desde por la mayoría de APIs de pago, resuelve ese dilema poniendo el control del retry en manos del cliente. ...

Consumir una API externa parece inofensivo al principio. Haces un requests.get, recibes un diccionario, y lo usas tal cual en el resto del código. El problema empieza cuando esa misma estructura JSON termina diseminada en diez archivos, y la API renombra un campo o cambia price de float a string. Corregirlo se convierte en una búsqueda del tesoro. La capa anti-corrupción (Anti-Corruption Layer, o ACL) responde a este problema. Procedente del Domain-Driven Design, actúa como un traductor entre un sistema externo y tu lógica de negocio. Un solo punto de contacto, un solo lugar que modificar cuando la API cambia. ...

Los permisos en Django REST Framework funcionan, pero muestran sus límites en cuanto las reglas de acceso se vuelven moderadamente complejas. Varios roles, objetos pertenecientes a un usuario específico, acciones custom en un ViewSet: acabas con clases has_permission y has_object_permission que mezclan verificaciones heterogéneas, difíciles de leer y aún más difíciles de testear. rest_access_policy (paquete djangorestframework-access-policy) propone un enfoque diferente: declarar las reglas de acceso como statements, similar a las políticas IAM de AWS. El resultado es legible de un vistazo, testeable independientemente del ViewSet, y extensible sin reescribir toda la clase. ...

En los equipos se escucha con frecuencia “tenemos una API REST”. Pero al revisar las respuestas JSON, no hay ningún enlace. Solo datos en crudo. Eso no es REST, es CRUD expuesto en HTTP. La diferencia la marca un principio que la mayoría de los desarrolladores ignora: HATEOAS. ¿Qué es HATEOAS en una API REST? HATEOAS significa Hypermedia As The Engine Of Application State. Es una de las restricciones fundamentales del REST, definida por Roy Fielding en su tesis del año 2000. ...