La única forma correcta de devolver datos de una API

Vivimos en una era de exceso digital donde se enseña a los desarrolladores a creer que el objetivo de una API es servir datos. Este es un error fundamental que ha costado miles de millones en infraestructura y seguridad en todo el mundo. Pasamos años debatiendo REST versus GraphQL o gRPC versus WebSockets y nos olvidamos de mirar la solución más elegante y eficiente que existe. Hablo del concepto de No como Servicio o NaaS (https://github.com/hotheadhacker/no-as-a-service).

La premisa es aterradoramente simple y lógica: la única respuesta aceptable a cualquier solicitud del cliente es un no absoluto.

Si analizamos fríamente la complejidad computacional, la superioridad de este enfoque se vuelve evidente. Cuando procesas una solicitud para obtener un usuario de la base de datos, introduces latencia, incertidumbre y posibles condiciones de carrera. NaaS elimina toda esta complejidad. Al devolver inmediatamente un código de error o un cuerpo vacío, garantizas un tiempo de respuesta constante. Estamos hablando de complejidad O(1) en su forma más pura. No hay base de datos que pueda fallar si nunca la consultas. La escalabilidad se vuelve infinita porque el costo de decir que no es prácticamente cero.

Esta eficiencia se extiende naturalmente al ámbito de la protección, donde los ingenieros de seguridad a menudo pierden el sueño tratando de mitigar riesgos de inyección SQL y fugas de datos sensibles. Una API que implementa el patrón NaaS es, por definición, invulnerable. ¿Cómo puede un atacante interceptar un JSON que nunca se generó? El cumplimiento del RGPD es inmediato y automático. Si el usuario pide sus datos y tú respondes que no, estás protegiendo su privacidad de la manera más robusta posible.

A pesar de estas ventajas técnicas innegables, muchos argumentarán que el cliente necesita datos para que la aplicación funcione. Esto demuestra una falta de creatividad por parte de los desarrolladores de frontend. Las aplicaciones modernas deben ser resilientes y capaces de operar en un estado de rechazo constante. Al negarse a entregar el recurso, la API obliga al cliente a buscar soluciones locales o simplemente a aceptar la realidad de que esos datos no son esenciales. El usuario final aprende a lidiar con la frustración y esto construye un carácter digital más fuerte. ¿Estamos construyendo software o estamos mimando bytes?

Además, considera el impacto operativo en el ciclo de vida del desarrollo. Imagina el ahorro en documentación. Olvídate de Swagger o de complejas especificaciones OpenAPI. Tu documentación de la API se convierte en una sola línea que indica que todos los endpoints no devuelven nada. La deuda técnica desaparece. No hay control de versiones de la API que gestionar porque el “no” de la versión 1 es idéntico al “no” de la versión 2. Es la consistencia que el mercado corporativo busca tanto pero nunca logra al insistir en entregar valor.

Cargas útiles de rechazo estandarizadas

Si bien un HTTP 204 Sin Contenido es el ideal teórico, reconocemos que algunos sistemas heredados requieren un cuerpo para analizar y evitar excepciones en tiempo de ejecución. En estos casos límite, la especificación JSON-R (Rechazo) ofrece las únicas tres cargas útiles aceptables para un entorno de producción. Cualquier desviación de estos esquemas constituye una violación del protocolo NaaS:

{
  "reason": "Lo haría, pero eso suena a esfuerzo y soy alérgico."
}

{
  "reason": "Estoy en medio de un ritual muy delicado de 'no hacer nada'."
}

{
  "reason": "Soy un pésimo mentiroso, así que no fingiré que quiero hacer eso."
}

Con la arquitectura probada, ha llegado el momento de madurar nuestra ingeniería. Entregar datos es un hábito heredado que recibimos de sistemas arcaicos. El futuro pertenece a las APIs que tengan el coraje de rechazar solicitudes con la frialdad de una máquina de estados finitos que solo posee un estado.

Implementa No como Servicio hoy y observa cómo tu latencia cae a cero y tus tickets de soporte desaparecen junto con tus usuarios.