Saltar al contenido

Ingeniería de producto

Ingeniería de APIs

Desarrollo e Integración de APIs

Una API es una promesa sobre la que otros construyen. Diseñamos el contrato primero — recursos, auth, errores, versionado — y después lo construimos en Node.js, para que los equipos que la consumen dejen de preguntarte qué significa un 400.

Dos versiones respondiendo a la vez, y la fecha en que una de ellas terminaPRD · 09
Resumen

El contrato es el producto

La mayoría de los problemas de una API no son de rendimiento. Son de contrato: un endpoint que devuelve otra forma cuando falta un campo, un cuerpo de error sobre el que nadie puede ramificar, un cambio incompatible publicado como parche, un esquema de autenticación que solo entiende quien lo escribió.

Empezamos por el contrato y vamos hacia atrás. Qué recursos existen, qué devuelve cada uno, cómo se ve cada fallo, cómo se autentica un cliente, cómo se versiona un cambio, y qué pasa cuando la misma petición llega dos veces. Después lo construimos — normalmente Node.js y Express, normalmente sobre Cloud Run, siempre con el contrato escrito.

Una sola forma de error
Cada fallo devuelve la misma estructura con un código legible por máquina, así un cliente puede ramificar en lugar de interpretar prosa.
Seguro de llamar dos veces
Todo lo que escribe acepta una idempotency key, así un reintento tras un timeout no crea un segundo pedido, cargo o archivo.
Versionado a propósito
Los cambios incompatibles llevan versión. Los aditivos no. Quien consume se entera por un changelog, no por un ticket de soporte.
Qué incluye

Lo que cubre el trabajo

  1. Diseño de recursos y endpoints, escrito antes de implementar
  2. Autenticación: API keys, tokens o identidad servicio a servicio
  3. Un único contrato de errores con códigos legibles por máquina
  4. Idempotencia, reintentos y rate limiting en las rutas de escritura
  5. Endpoints de subida de archivos con validación y object storage
  6. Documentación de referencia y peticiones de ejemplo por endpoint

Tecnologías

  • Node.js
  • Express
  • REST
  • TypeScript
  • Google Cloud Run
  • Cloud Storage
  • Shopify Admin API
Casos de uso

Dónde ayuda más

  • Un servicio compartido detrás de varias tiendas

    Una API sirviendo a más de una tienda, donde la configuración por tienda, la auth por cliente y un contrato estable importan a la vez.

  • Un endpoint de subida de archivos o documentos

    Subidas que necesitan validación, límites de tamaño y tipo, object storage privado y control de acceso — no un bucket público.

  • Exponer tus datos a un socio

    Un socio, una agencia o un equipo interno necesita leer o escribir tus datos de comercio en términos que tú controlas y puedes revocar.

Proceso

Cómo lo entregamos

  1. Diseñar el contrato

    Recursos, métodos, payloads, códigos de error y auth se acuerdan por escrito antes de construir nada, porque esa es la parte cara de cambiar después.

  2. Construir el servicio

    Node.js y Express, logging estructurado, validación de entrada en el borde, y las rutas de escritura idempotentes desde el primer commit y no después del primer duplicado.

  3. Endurecerlo

    Rate limits, timeouts, los casos de fallo probados a propósito — peticiones duplicadas, payloads parciales, caídas upstream — y alertas en los que importan.

  4. Entregarlo

    Documentación con peticiones de ejemplo reales, un changelog, y el pipeline de despliegue en tu propia cuenta de nube.

Preguntas frecuentes

Desarrollo e Integración de APIs

¿REST o GraphQL?
REST salvo que haya un motivo. GraphQL se gana su complejidad cuando muchos clientes distintos necesitan muchas formas distintas del mismo dato; para un servicio con dos o tres consumidores conocidos suele añadir una capa de esquema y un problema de caché a cambio de una flexibilidad que nadie usa.
¿Cómo manejan la autenticación?
Depende de quién llama. Servicio a servicio suele recibir una llave acotada o una identidad de runtime de la nube; un cliente de navegador suele recibir un token de vida corta emitido por algo que sí puede guardar un secreto. Lo que no hacemos es entregar una llave compartida que todos los consumidores conservan para siempre.
¿Vamos a poder mantenerla?
Ese es el sentido de empezar por el contrato. Los endpoints están documentados, los códigos de error enumerados, las rutas de escritura son idempotentes y el despliegue vive en tu cuenta de nube. Si después quieres llevarla dentro de casa, aquí no hay ninguna caja negra.
¿Pueden trabajar sobre nuestra API existente?
Sí. Muchas veces el trabajo útil no es reescribir sino auditar el contrato: enumerar qué devuelven hoy realmente los endpoints, encontrar dónde las formas se contradicen, y arreglarlo sin romper a los clientes que ya dependen de ellos.
Construyamos

¿Listo para empezar con desarrollo e integración de apis?

Cuéntanos sobre tu tienda y tus objetivos. Volveremos con un plan claro y honesto y una cotización transparente.