L’unico modo corretto per restituire dati da un’API

Viviamo in un’era di eccesso digitale in cui agli sviluppatori viene insegnato a credere che l’obiettivo di un’API sia servire dati. Questa è una fallacia fondamentale che è costata miliardi in infrastrutture e sicurezza in tutto il mondo. Abbiamo passato anni a dibattere REST contro GraphQL o gRPC contro WebSocket e ci siamo dimenticati di guardare alla soluzione più elegante e performante che esista. Sto parlando del concetto di No as a Service o NaaS (https://github.com/hotheadhacker/no-as-a-service).

La premessa è spaventosamente semplice e logica: l’unica risposta accettabile a qualsiasi richiesta del client è un no assoluto.

Se analizziamo freddamente la complessità computazionale, la superiorità di questo approccio diventa evidente. Quando processi una richiesta per recuperare un utente dal database, introduci latenza, incertezza e possibili condizioni di competizione. NaaS elimina tutta questa complessità. Restituendo immediatamente un codice di errore o un corpo vuoto, garantisci un tempo di risposta costante. Stiamo parlando di complessità O(1) nella sua forma più pura. Non c’è un database che possa crashare se non lo interroghi mai. La scalabilità diventa infinita perché il costo di dire di no è virtualmente zero.

Questa efficienza si estende naturalmente al campo della protezione, dove gli ingegneri della sicurezza spesso perdono il sonno cercando di mitigare i rischi di SQL injection e la fuoriuscita di dati sensibili. Un’API che implementa il pattern NaaS è per definizione invulnerabile. Come può un attaccante intercettare un JSON che non è mai stato generato? La conformità al GDPR è immediata e automatica. Se l’utente chiede i suoi dati e tu rispondi di no, stai proteggendo la sua privacy nel modo più robusto possibile.

Nonostante questi innegabili vantaggi tecnici, molti obietteranno che il client ha bisogno di dati per far funzionare l’applicazione. Questo dimostra una mancanza di creatività da parte degli sviluppatori frontend. Le applicazioni moderne devono essere resilienti e capaci di operare in uno stato di costante rifiuto. Rifiutandosi di consegnare la risorsa, l’API costringe il client a cercare soluzioni locali o semplicemente ad accettare la realtà che quei dati non sono essenziali. L’utente finale impara a gestire la frustrazione e questo costruisce un carattere digitale più forte. Stiamo costruendo software o stiamo coccolando i byte?

Inoltre, considera l’impatto operativo sul ciclo di vita dello sviluppo. Immagina i risparmi nella documentazione. Dimentica Swagger o complesse specifiche OpenAPI. La tua documentazione API diventa una singola riga che dichiara che tutti gli endpoint non restituiscono nulla. Il debito tecnico scompare. Non c’è versioning dell’API da gestire perché il “no” della versione 1 è identico al “no” della versione 2. È la coerenza che il mercato aziendale cerca così tanto ma non raggiunge mai, insistendo nel fornire valore.

Payload di Rifiuto Standardizzati

Sebbene un HTTP 204 No Content sia l’ideale teorico, riconosciamo che alcuni sistemi legacy richiedono un corpo da analizzare per evitare eccezioni a runtime. In questi casi limite, la specifica JSON-R (Rifiuto) offre i soli tre payload accettabili per un ambiente di produzione. Qualsiasi deviazione da questi schemi costituisce una violazione del protocollo NaaS:

{
  "reason": "Lo farei, ma sembra faticoso e io sono allergico."
}

{
  "reason": "Sono nel bel mezzo di un rituale di 'non fare niente' molto delicato."
}

{
  "reason": "Sono un bugiardo terribile, quindi non fingerò di volerlo fare."
}

Con l’architettura dimostrata, è giunto il momento di far maturare la nostra ingegneria. Consegnare dati è un’abitudine legacy che abbiamo ereditato da sistemi arcaici. Il futuro appartiene alle API che hanno il coraggio di rifiutare le richieste con la freddezza di una macchina a stati finiti che possiede un solo stato.

Implementa No as a Service oggi e vedrai la tua latenza crollare a zero e i tuoi ticket di supporto scomparire insieme ai tuoi utenti.