Chi stima il costo di sviluppo di un’API su misura partendo dal numero di endpoint sbaglierà, di solito di un fattore tre. Gli endpoint sono la parte meno costosa. Una dozzina di essi, che leggono e scrivono dati che già possiedi, sono due settimane di lavoro per uno sviluppatore back-end competente.

Quello che costa è tutto ciò che trasforma quegli endpoint in qualcosa su cui un’altra azienda costruirà il proprio business: un’autenticazione che sopravvive a un audit di sicurezza, un versionamento che ti lascia cambiare idea più avanti, una documentazione abbastanza buona da non farti scrivere email, e l’apparato operativo che ti dice quale cliente sta avendo una brutta mattinata. Il budget vive nello spazio fra “abbiamo un’API” e “abbiamo un’API su cui altri fanno affidamento”.

Le fasce di prezzo in breve: un’API interna consumata solo dalle tue applicazioni costa in genere fra 10.000 e 30.000 sterline. Un’API per partner, usata da una manciata di integratori noti, si colloca di norma fra 40.000 e 100.000 sterline. Un’API pubblica che fa parte del prodotto, con registrazione self-service e contratto pubblicato, parte da circa 100.000 sterline e continua a costare dopo il lancio.

Che cosa stai comprando davvero

Un’API è un prodotto con utenti, e ha bisogno di ciò di cui hanno bisogno i prodotti. Confrontare questo elenco con un preventivo è il modo più rapido per vedere che cosa ne è stato tolto.

Progettazione e contratto. Qualcuno deve decidere il modello delle risorse, le convenzioni di denominazione, il formato degli errori, l’impaginazione e la sintassi dei filtri, e poi metterlo per iscritto come specifica prima che l’implementazione cominci. Saltare questo passaggio produce un’API in cui tre endpoint risolvono lo stesso problema in tre modi diversi, e i consumatori se ne accorgono subito.

Autenticazione e autorizzazione. Le chiavi API sono semplici e adatte all’uso interno. Le API per partner e quelle pubbliche richiedono in genere un vero flusso basato su token, con ambiti, scadenza e rotazione, oltre a permessi per singolo consumatore verificati a ogni richiesta anziché dedotti dalla chiave.

Limiti di frequenza e quote. I limiti per consumatore proteggono la tua infrastruttura dal processo batch impazzito di un singolo integratore. Devono anche essere comunicati negli header di risposta, perché i client ben educati possano rallentare, e serve una via d’eccezione per il cliente che ha legittimamente bisogno di più.

Le parti su cui i consumatori ti giudicano

La documentazione. Un riferimento generato è il minimo indispensabile. Quello di cui i consumatori hanno davvero bisogno è una guida introduttiva, un percorso di autenticazione, esempi svolti in un paio di linguaggi e un registro delle modifiche. Una buona documentazione è un vero deliverable, misurato in settimane, ed è la differenza fra un’API che si adotta da sola e una che genera ticket di supporto per sempre.

Un ambiente sandbox. I partner non testeranno sulla produzione, e non dovresti volerlo. Un ambiente di prova con dati realistici, stato ripristinabile e le stesse regole di validazione è una delle voci più spesso omesse in un preventivo per un’API, e una delle funzionalità più richieste dopo il lancio.

L’osservabilità. Devi vedere volumi di richieste, tassi di errore e latenza suddivisi per consumatore, perché “l’API è lenta” diventa azionabile solo se sai di chi sono le richieste lente. Gli identificatori di correlazione, che permettono di seguire la chiamata fallita di un cliente attraverso i log, si ripagano già nel primo mese di supporto.

Il collaudo. Oltre agli unit test, un’API ha bisogno di test di contratto che facciano fallire la build quando la forma di una risposta cambia involontariamente. È quella rete di sicurezza a permetterti di continuare a sviluppare senza rompere gli integratori che si sono fidati di te.

I tre livelli, e perché differiscono così tanto

Lo stesso insieme di endpoint costa cifre molto diverse a seconda di chi lo consuma, perché è il pubblico a determinare quanta imperfezione è tollerabile.

Le API interne servono le tue applicazioni. Il tuo team controlla entrambi i capi, le modifiche non retrocompatibili si possono coordinare, la documentazione può restare asciutta e l’autenticazione può appoggiarsi ai confini di rete. Costo tipico: da 10.000 a 30.000 sterline per un servizio ben costruito, con test e monitoraggio sensati.

Le API per partner servono un insieme noto di organizzazioni esterne. Ora servono autenticazione reale, messaggi di errore significativi, una sandbox, documentazione scritta e una politica di versionamento, perché non puoi rilasciare una modifica non retrocompatibile un martedì pomeriggio aspettandoti che tutti stiano al passo. Costo tipico: da 40.000 a 100.000 sterline a seconda del numero di risorse e della severità dei requisiti di sicurezza.

Le API pubbliche o di prodotto servono chiunque si registri. Registrazione self-service, gestione delle chiavi, limiti di frequenza pubblicati, una pagina di stato, misurazione a consumo, documentazione completa e un processo di supporto diventano tutti necessari. Se la fatturazione dipende dall’uso, hai aggiunto anche un sistema di misurazione e riconciliazione. Costo tipico: da 100.000 sterline in su, e il lancio è l’inizio della spesa anziché la fine.

Decidere onestamente quale livello stai costruendo è la mezz’ora più preziosa del progetto. Quasi tutti gli sforamenti di questa categoria nascono dall’aver dimensionato un’API interna per poi scoprire, tre mesi dopo, che un partner l’avrebbe comunque usata.

Dove finisce davvero il costo di sviluppo di un’API

Per un’API di qualità adatta ai partner l’impegno si distribuisce in modo abbastanza prevedibile, e raramente come se lo aspettano i responsabili.

Circa un quinto va in progettazione e specifica, comprese le discussioni sulla denominazione delle risorse che sembrano uno spreco e prevengono mesi di incoerenza. Un altro quinto circa va nell’implementazione degli endpoint veri e propri, cioè la parte che tutti immaginano quando approvano il budget.

Autenticazione, autorizzazione e limiti di frequenza insieme assorbono comunemente dal quindici al venti per cento, e di più se ti stai innestando su un provider di identità esistente che ha le sue opinioni. Documentazione, sandbox ed eventuali librerie client prendono una quota simile, il che sorprende finché non si prova a scrivere una buona guida introduttiva.

Collaudo, osservabilità e rilascio consumano il resto. Quest’ultimo quarto è la porzione che più facilmente viene tagliata quando una scadenza si avvicina, e tagliarla è ciò che trasforma un costo di costruzione una tantum in un onere di supporto permanente.

Per capire come questo si inserisce nel resto di un budget di consegna, la nostra guida ai costi dello sviluppo software personalizzato descrive le voci circostanti.

Le decisioni che spostano la cifra

Una manciata di scelte spiega gran parte della differenza fra due preventivi.

Sincrono o asincrono. Se un’operazione richiede più di un secondo o due, ti serve un modello a job: accetti la richiesta, restituisci un riferimento e lasci che il consumatore faccia polling o riceva una callback. È una costruzione sensibilmente più grande di una semplice richiesta e risposta, e offrire webhook significa che ora gestisci un sistema di consegna tutto tuo, con ritentativi, verifica delle firme e un archivio per i messaggi non recapitabili.

Multi-tenancy. Garantire che un cliente non veda mai i dati di un altro è facile da descrivere e facile da sbagliare in modo sottile. Farlo bene, con l’autorizzazione verificata a livello di accesso ai dati anziché in ogni controller, costa di più e non è facoltativo.

Obblighi di conformità. Trattare dati personali, informazioni di pagamento o dati sanitari porta con sé registri di audit, regole di conservazione, requisiti di cifratura e raccolta di evidenze. Raramente compaiono in una stima iniziale e non sono mai negoziabili dopo.

Impegni sul livello di servizio. Un’API con un obiettivo di disponibilità contrattuale richiede ridondanza, allarmi e qualcuno reperibile. È un costo di esercizio e non di costruzione, e va quotato separatamente perché nessuno resti sorpreso.

Fondamenta esistenti. Costruire su una base di codice che ha già autenticazione, elaborazioni in background e monitoraggio è enormemente più economico che partire da zero. Se ti serve anche la piattaforma sottostante, la nostra guida alla creazione di un’API serverless con Cloudflare Workers mostra un approccio che tiene bassi i costi di infrastruttura.

I costi che arrivano dopo il lancio

Un’API è una promessa, e le promesse hanno costi correnti.

Il versionamento è il maggiore. Una volta che consumatori esterni dipendono dalla forma delle tue risposte, non puoi più cambiarla liberamente. Mantenere due versioni in parallelo mentre gli integratori migrano è normale, e significa che per un periodo ogni correzione va applicata due volte. Una politica di deprecazione pubblicata con preavviso generoso rende la cosa gestibile; la sua assenza trasforma ogni miglioramento in una trattativa.

Il supporto è il secondo. Anche una documentazione eccellente genera domande, e le domande sono abbastanza tecniche da arrivare a uno sviluppatore invece di fermarsi a uno sportello. Metti a budget tempo di ingegneria vero, in particolare nei mesi successivi all’attivazione di ogni nuovo partner.

La manutenzione della documentazione è il terzo e il più trascurato. Esempi che non funzionano più sono peggio di nessun esempio, ed erodono la fiducia più in fretta di un disservizio.

Come cifra di pianificazione, prevedi ogni anno dal quindici al venticinque per cento del costo iniziale di costruzione per mantenere sana un’API per partner o pubblica. Se l’API è essa stessa una linea di ricavo, la nostra guida ai modelli di licenza software spiega come strutturare il lato commerciale.

Come evitare che il progetto raddoppi

Tre abitudini tengono i progetti di API dentro la stima.

Scrivi prima la specifica e falla rivedere da un consumatore reale prima che l’implementazione cominci. Un’ora di riscontri dal team che integrerà davvero risparmia settimane di rilavorazione, e fa emergere il requisito che nessuno aveva menzionato.

Costruisci un endpoint per intero, passando per autenticazione, gestione degli errori, documentazione, test e monitoraggio, prima di costruire gli altri venti. Il primo rivela il costo reale per endpoint, e lo fa mentre il budget può ancora assorbire la notizia.

Sii spietato con l’elenco iniziale delle risorse. Quasi tutte le API vengono lanciate con più endpoint di quanti ne usi chiunque, e ogni endpoint inutilizzato va comunque documentato, testato, protetto e versionato finché esiste. Rilascia la superficie utile più piccola ed estendila quando l’uso reale ti dirà che cosa manca.

Costruisci un’API che gli altri vogliano integrare

Mecanik progetta e costruisce API nell’ambito dei nostri servizi di sviluppo software personalizzato , dai servizi interni fino alle API pubbliche di prodotto con registrazione self-service. Trattiamo specifica, documentazione e sandbox come deliverable e non come ripensamenti, perché sono loro a determinare se qualcuno riuscirà davvero a integrarsi.

Se ti trovi dall’altro lato del problema e consumi l’API di qualcun altro invece di pubblicare la tua, la nostra guida all’integrazione di API di terze parti spiega a che cosa fare attenzione. Altrimenti dicci chi sono i consumatori e che cosa devono poter fare, e definiremo l’ambito livello per livello, così vedrai esattamente quanto costa ciascun grado di ambizione.

Post correlati: Outsourcing dello sviluppo software nel Regno Unito , Integrazione CRM ed ERP: costi, metodi e insidie , Modernizzazione mainframe: rewrite, refactor o replatform .

Domande frequenti

Quanto costa lo sviluppo di un’API su misura? Un’API interna costa in genere fra 10.000 e 30.000 sterline, un’API per partner fra 40.000 e 100.000, e un’API pubblica di prodotto oltre 100.000. È il pubblico a determinare il prezzo molto più del numero di endpoint, perché i consumatori esterni richiedono documentazione, sandbox, versionamento e supporto.

Quanto tempo serve per costruire un’API su misura? Un servizio interno richiede di solito da quattro a otto settimane. Un’API di qualità adatta ai partner richiede in genere da tre a cinque mesi, documentazione e ambiente sandbox compresi. Le API pubbliche con registrazione self-service e misurazione a consumo richiedono comunemente sei mesi o più prima del lancio.

Che cosa rende lo sviluppo di API più costoso del previsto? Documentazione, ambienti sandbox, limiti di frequenza per consumatore, supporto al versionamento e osservabilità. Raramente compaiono nelle stime iniziali e insieme rappresentano spesso metà dell’impegno totale su un’API per partner o pubblica.

Meglio costruire un’API REST o GraphQL? REST resta la scelta predefinita più sicura per le API destinate a partner e pubblico, perché strumenti, caching e familiarità degli sviluppatori sono più diffusi. GraphQL si adatta all’uso interno e alle applicazioni client ricche, ma sposta il costo sui limiti di complessità delle query e sull’autorizzazione.

Quali costi ricorrenti aspettarsi dopo il lancio di un’API? Prevedi ogni anno dal quindici al venticinque per cento del costo di costruzione. Copre il mantenimento di versioni parallele durante i periodi di deprecazione, il tempo di ingegneria speso a rispondere alle domande di integrazione, l’aggiornamento della documentazione e il monitoraggio necessario per i consumatori esterni.