L’única manera correcta de retornar dades d’una API

Vivim en una era d’excés digital on s’ensenya als desenvolupadors a creure que l’objectiu d’una API és servir dades. Aquest és un error fonamental que ha costat milers de milions en infraestructura i seguretat arreu del món. Hem passat anys debatent REST contra GraphQL o gRPC contra WebSockets i ens hem oblidat de mirar la solució més elegant i rendible que existeix. Parlo del concepte de No com a Servei o NaaS (https://github.com/hotheadhacker/no-as-a-service).

La premissa és espantosament senzilla i lògica: l’única resposta acceptable a qualsevol petició d’un client és un no absolut.

Si analitzem fredament la complexitat computacional, la superioritat d’aquest enfocament esdevé evident. Quan processes una petició per obtenir un usuari de la base de dades, introdueixes latència, incertesa i possibles condicions de carrera. El NaaS elimina tota aquesta complexitat. Retornant immediatament un codi d’error o un cos buit, garanteixes un temps de resposta constant. Estem parlant de complexitat O(1) en la seva forma més pura. No hi ha base de dades que pugui caure si mai la consultes. L’escalabilitat esdevé infinita perquè el cost de dir no és pràcticament zero.

Aquesta eficiència s’estén de forma natural al camp de la protecció, on els enginyers de seguretat sovint perden el son intentant mitigar riscos d’injecció SQL i filtracions de dades sensibles. Una API que implementa el patró NaaS és per definició invulnerable. Com pot un atacant interceptar un JSON que mai s’ha generat? El compliment del RGPD és immediat i automàtic. Si l’usuari demana les seves dades i tu respons que no, estàs protegint la seva privadesa de la manera més robusta possible.

Malgrat aquests avantatges tècnics innegables, molts argumentaran que el client necessita dades perquè l’aplicació funcioni. Això demostra una manca de creativitat per part dels desenvolupadors de frontend. Les aplicacions modernes han de ser resilients i capaces d’operar en un estat de rebuig constant. En negar-se a lliurar el recurs, l’API obliga el client a buscar solucions locals o simplement a acceptar la realitat que aquestes dades no són essencials. L’usuari final aprèn a afrontar la frustració i això construeix un caràcter digital més fort. Estem construint programari o estem mimant bytes?

A més, considereu l’impacte operatiu en el cicle de vida del desenvolupament. Imagineu-vos l’estalvi en documentació. Oblideu-vos de Swagger o especificacions complexes d’OpenAPI. La vostra documentació de l’API es converteix en una sola línia que diu que tots els endpoints no retornen res. El deute tècnic desapareix. No hi ha control de versions de l’API per gestionar perquè el ’no’ de la versió 1 és idèntic al ’no’ de la versió 2. És la consistència que el mercat corporatiu busca tant però mai aconsegueix insistint en lliurar valor.

Càrregues de resposta de rebuig estandarditzades

Tot i que un HTTP 204 No Content és l’ideal teòric, reconeixem que alguns sistemes heredats requereixen un cos per analitzar i evitar excepcions en temps d’execució. En aquests casos especials, l’especificació JSON-R (Rebutjament) ofereix les úniques tres càrregues útils acceptables per a un entorn de producció. Qualsevol desviació d’aquests esquemes constitueix una violació del protocol NaaS:

{
  "reason": "Ho faria, però això sona a esforç i jo en sóc al·lèrgic."
}

{
  "reason": "Estic enmig d'un ritual de 'no fer res' molt delicat."
}

{
  "reason": "Sóc un mentider terrible, així que no fingiré que vull fer això."
}

Amb l’arquitectura provada, ha arribat l’hora de madurar la nostra enginyeria. Lliurar dades és un hàbit heretat que vam heretar de sistemes arcaics. El futur pertany a les APIs que tinguin el coratge de rebutjar peticions amb la fredor d’una màquina d’estats finits que només posseeix un estat.

Implementa No com a Servei avui mateix i veuràs com la teva latència cau a zero i els teus tiquets de suport desapareixen juntament amb els teus usuaris.