Desarrollo de APIs

Problemas de negocio

• Móvil, dashboard y partners cada uno con un backend distinto, así que la misma regla de negocio — un descuento, una comprobación de permisos — se implementa tres veces y diverge.
• Una API sin estrategia de versionado, así que cada cliente está siempre a un deploy de romperse.
• Una API sin ningún límite de tasa, así que un cliente que se comporta mal o un bucle de reintentos de una integración de partner puede tumbar el backend para todos.
• Lógica de autenticación duplicada en los endpoints en vez de centralizada, así que una corrección de seguridad tiene que aplicarse en una docena de sitios y inevitablemente se olvida uno.
• Sin entorno de staging o sandbox para que los partners prueben, así que el primer intento de integración de un partner ocurre directamente contra datos de producción.
• Sin convención de nomenclatura o forma consistente entre endpoints, así que un cliente tiene que aprender un patrón ligeramente distinto para cada recurso en vez de uno que valga en todas partes.
• Claves API de larga duración sin expiración ni restricción de alcance, así que una sola clave filtrada otorga acceso total indefinidamente en vez de uno acotado y limitado en el tiempo.

Proceso de desarrollo

1. Recursos, auth, errores, versiones — un contrato que otros equipos pueden mantener, documentado lo bastante bien para que un consumidor nuevo no necesite una llamada para entender cómo usarlo.
2. Diseñar las formas de error y paginación una vez, por adelantado, para que cada endpoint nuevo siga el mismo patrón en vez de inventar el suyo.
3. Centralizar autenticación y autorización en middleware, no en cada controlador, para que una regla de permisos se defina una vez y se aplique de forma consistente en todas partes.
4. Añadir límite de tasa y registro de peticiones desde el inicio, para que un pico de tráfico o un cliente abusivo sea visible y se frene en vez de tumbar la API.
5. Proporcionar un entorno sandbox con datos de prueba realistas, para que un partner pueda construir y probar una integración sin tocar producción.
6. Elegir una convención de nomenclatura y forma de respuesta para toda la API el primer día, y aplicarla a cada endpoint siguiente, para que un recurso nuevo sea predecible antes incluso de leer su documentación.

Qué obtienes

• Una API para web y móvil que se mantiene estable al crecer el producto, para que un release móvil no tenga que ir al mismo ritmo que cada cambio de backend.
• Partners y equipos internos construyendo sobre el mismo contrato documentado en vez de hacer ingeniería inversa del comportamiento desde una colección de Postman reenviada una vez.
• Una API que sobrevive a un pico de tráfico o a un cliente que se comporta mal en vez de caer con él.
• Correcciones de seguridad aplicadas una vez, en el middleware, en vez de perseguidas por una docena de endpoints esperando no haberse dejado ninguno.
• Partners que pueden construir y probar contra un sandbox en vez de experimentar directamente sobre datos de producción.
• Endpoints nuevos que se sienten familiares en cuanto un cliente los ve, porque siguen la misma convención que el resto de la API.
• Claves API acotadas exactamente a lo que una integración necesita y nada más, para que una filtración sea un incidente contenido en vez de un compromiso total.
• Menos bugs de integración reportados por partners, porque la API se comporta igual en todas partes en vez de sorprenderlos en el único endpoint que nadie probó con cuidado.

Proyectos seleccionados