Oricine estimează costul dezvoltării unui API personalizat pornind de la numărul de endpointuri va greși, de obicei de trei ori. Endpointurile sunt partea cea mai ieftină. O duzină dintre ele, care citesc și scriu date pe care le dețineți deja, înseamnă două săptămâni de lucru pentru un dezvoltator backend competent.

Costă tot ceea ce transformă acele endpointuri în ceva pe care o altă companie își va construi afacerea: o autentificare ce trece de un audit de securitate, o versionare care vă lasă să vă răzgândiți mai târziu, o documentație suficient de bună încât nimeni să nu vă mai scrie și aparatul operațional care vă spune ce client are o dimineață proastă. Bugetul stă în distanța dintre „avem un API" și „avem un API pe care se bazează alții".

Benzile de preț pe scurt: un API intern, consumat doar de propriile aplicații, costă de regulă între 10.000 și 30.000 de lire sterline. Un API pentru parteneri, folosit de câțiva integratori cunoscuți, ajunge în general între 40.000 și 100.000 de lire sterline. Un API public care face parte din produs, cu înrolare în autoservire și contract publicat, pornește de la circa 100.000 de lire sterline și continuă să coste după lansare.

Ce cumpărați de fapt

Un API este un produs cu utilizatori și are nevoie de ceea ce au nevoie produsele. Confruntarea acestei liste cu o ofertă este cea mai rapidă cale de a vedea ce a fost scos din ea.

Proiectare și contract. Cineva trebuie să decidă modelul de resurse, convențiile de denumire, formatul erorilor, modul de paginare și sintaxa de filtrare, apoi să le scrie ca specificație înainte de începerea implementării. Sărirea peste acest pas produce un API în care trei endpointuri rezolvă aceeași problemă în trei feluri diferite, iar consumatorii observă imediat.

Autentificare și autorizare. Cheile de API sunt simple și potrivite pentru uz intern. API-urile pentru parteneri și cele publice au nevoie, de regulă, de un flux real bazat pe token, cu domenii de acces, expirare și rotație, plus permisiuni per consumator verificate la fiecare cerere, nu deduse din cheie.

Limitarea ratei și cotele. Limitele per consumator vă protejează infrastructura de procesarea scăpată de sub control a unui singur integrator. Ele trebuie comunicate și în anteturile răspunsului, ca aplicațiile bine crescute să încetinească, și au nevoie de o cale de excepție pentru clientul care are nevoie legitimă de mai mult.

Părțile după care vă judecă consumatorii

Documentația. O referință generată automat este strictul necesar. Ce le trebuie consumatorilor cu adevărat este un ghid de pornire, un parcurs de autentificare, exemple lucrate în câteva limbaje și un jurnal al modificărilor. Documentația bună este un livrabil real, măsurat în săptămâni, și face diferența între un API care se adoptă singur și unul care generează tichete de asistență la nesfârșit.

Un mediu de test. Partenerii nu vor testa pe producție și nici nu ar trebui să vă doriți asta. Un mediu de test cu date realiste, stare care poate fi resetată și aceleași reguli de validare este una dintre cele mai des omise linii dintr-o ofertă de API și una dintre cele mai cerute funcții după lansare.

Observabilitatea. Trebuie să vedeți volumul cererilor, rata erorilor și latența defalcate pe consumator, pentru că „API-ul este lent" devine acționabil doar dacă puteți spune ale cui cereri sunt lente. Identificatorii de corelare, care vă lasă să urmăriți apelul eșuat al unui client prin jurnale, se amortizează în prima lună de asistență.

Testarea. Dincolo de testele unitare, un API are nevoie de teste de contract care pică build-ul atunci când forma unui răspuns se schimbă din greșeală. Această plasă de siguranță vă permite să continuați dezvoltarea fără să stricați integratorii care au avut încredere în voi.

Cele trei niveluri și de ce diferă atât de mult

Același set de endpointuri costă sume foarte diferite în funcție de cine le consumă, pentru că publicul stabilește cât de multă imperfecțiune este tolerabilă.

API-urile interne vă deservesc propriile aplicații. Echipa controlează ambele capete, schimbările incompatibile pot fi coordonate, documentația poate fi succintă, iar autentificarea se poate sprijini pe granițele de rețea. Cost tipic: între 10.000 și 30.000 de lire sterline pentru un serviciu bine construit, cu teste și monitorizare rezonabile.

API-urile pentru parteneri deservesc un set cunoscut de organizații externe. Acum aveți nevoie de autentificare reală, mesaje de eroare cu sens, un mediu de test, documentație scrisă și o politică de versionare, pentru că nu puteți livra o schimbare incompatibilă într-o marți după-amiază sperând că toată lumea ține pasul. Cost tipic: între 40.000 și 100.000 de lire sterline, în funcție de numărul de resurse și de severitatea cerințelor de securitate.

API-urile publice sau de produs deservesc pe oricine se înregistrează. Înregistrarea în autoservire, gestionarea cheilor, limitele de rată publicate, o pagină de stare, contorizarea la consum, documentația completă și un proces de asistență devin toate necesare. Dacă facturarea depinde de consum, ați adăugat și un sistem de măsurare și reconciliere. Cost tipic: de la 100.000 de lire sterline în sus, iar lansarea este începutul cheltuielii, nu sfârșitul ei.

Să decideți cinstit ce nivel construiți este cea mai valoroasă jumătate de oră a proiectului. Cele mai multe depășiri de buget din această categorie vin din a dimensiona un API intern și a descoperi, trei luni mai târziu, că un partener urma oricum să îl folosească.

Unde se duce de fapt costul dezvoltării unui API

Pentru un API de calitate pentru parteneri, efortul se distribuie destul de previzibil și rareori așa cum se așteaptă cei care aprobă bugetul.

Aproximativ o cincime merge în proiectare și specificație, inclusiv în discuțiile despre denumirea resurselor, care par o risipă și previn luni de inconsecvență. Încă o cincime merge în implementarea propriu-zisă a endpointurilor, adică exact partea pe care și-o imaginează toată lumea când aprobă bugetul.

Autentificarea, autorizarea și limitarea ratei iau împreună, de obicei, între cincisprezece și douăzeci la sută, și mai mult dacă vă conectați la un furnizor de identitate existent care are propriile păreri. Documentația, mediul de test și eventualele biblioteci client cer o pondere similară, ceea ce surprinde până când cineva încearcă să scrie un ghid de pornire bun.

Testarea, observabilitatea și livrarea consumă restul. Acest ultim sfert este porțiunea cel mai probabil tăiată când se apropie un termen, iar tăierea lui transformă un cost unic de construcție într-o povară permanentă de asistență.

Pentru a vedea cum se așază asta lângă restul unui buget de livrare, ghidul nostru privind costul dezvoltării de software personalizat descrie liniile din jur.

Deciziile care mișcă cifra

Câteva alegeri explică cea mai mare parte a diferenței dintre două oferte.

Sincron sau asincron. Dacă vreo operațiune durează mai mult de o secundă sau două, aveți nevoie de un model bazat pe sarcini: acceptați cererea, returnați o referință și lăsați consumatorul să interogheze sau să primească un apel invers. Este o construcție semnificativ mai mare decât o simplă cerere cu răspuns, iar oferirea de webhookuri înseamnă că acum operați un sistem de livrare propriu, cu reîncercări, verificarea semnăturii și un depozit pentru mesajele nelivrabile.

Multi-tenancy. Garantarea faptului că un client nu poate vedea niciodată datele altuia se descrie ușor și se greșește subtil la fel de ușor. Făcută corect, cu autorizarea verificată la stratul de acces la date în loc de fiecare controler, costă în plus și nu este opțională.

Obligațiile de conformitate. Prelucrarea datelor cu caracter personal, a datelor de plată sau a informațiilor medicale aduce jurnale de audit, reguli de păstrare, cerințe de criptare și colectare de dovezi. Acestea apar rar într-o estimare inițială și nu sunt niciodată negociabile ulterior.

Angajamentele privind nivelul serviciului. Un API cu o țintă contractuală de disponibilitate are nevoie de redundanță, alertare și cineva de gardă. Este un cost de operare, nu de construcție, și trebuie ofertat separat, ca nimeni să nu fie surprins.

Fundațiile existente. Construirea pe o bază de cod care are deja autentificare, procesare în fundal și monitorizare este dramatic mai ieftină decât pornirea de la zero. Dacă aveți nevoie și de platforma de dedesubt, ghidul nostru despre construirea unui API serverless cu Cloudflare Workers arată o abordare care ține costul de infrastructură jos.

Costurile care apar după lansare

Un API este o promisiune, iar promisiunile au costuri de funcționare.

Versionarea este cel mai mare dintre ele. Odată ce consumatori externi depind de forma răspunsurilor, nu o mai puteți schimba liber. Menținerea a două versiuni în paralel cât timp integratorii migrează este normală și înseamnă că fiecare corecție trebuie aplicată de două ori pentru o perioadă. O politică publicată de retragere, cu preaviz generos, face lucrurile gestionabile; absența ei transformă fiecare îmbunătățire în negociere.

Asistența este a doua. Chiar și o documentație excelentă generează întrebări, iar întrebările sunt suficient de tehnice încât să ajungă la un dezvoltator în loc să se oprească la un birou de suport. Bugetați timp real de inginerie pentru asta, mai ales în lunile de după intrarea în producție a fiecărui nou partener.

Întreținerea documentației este a treia și cea mai neglijată. Exemplele care nu mai funcționează sunt mai rele decât lipsa exemplelor și erodează încrederea mai repede decât o pană.

Ca reper de planificare, alocați anual între cincisprezece și douăzeci și cinci la sută din costul inițial de construcție pentru a menține sănătos un API pentru parteneri sau public. Dacă API-ul este el însuși o linie de venit, ghidul nostru despre modelele de licențiere software explică structurarea laturii comerciale.

Cum să nu se dubleze proiectul

Trei obiceiuri țin proiectele de API în limita estimării.

Scrieți întâi specificația și puneți un consumator real să o revizuiască înainte de începerea implementării. O oră de feedback de la echipa care va integra efectiv economisește săptămâni de refacere și scoate la iveală cerința pe care nimeni nu a menționat-o.

Construiți un singur endpoint complet, trecând prin autentificare, tratarea erorilor, documentație, teste și monitorizare, înainte de a le construi pe celelalte douăzeci. Primul dezvăluie costul real per endpoint și o face cât timp bugetul mai poate absorbi vestea.

Fiți necruțători cu lista inițială de resurse. Cele mai multe API-uri sunt lansate cu mai multe endpointuri decât folosește cineva, iar fiecare endpoint nefolosit trebuie totuși documentat, testat, securizat și versionat cât timp există. Livrați cea mai mică suprafață utilă și extindeți-o când utilizarea reală vă spune ce lipsește.

Construiți un API pe care oamenii vor să îl integreze

Mecanik proiectează și construiește API-uri ca parte a serviciilor noastre de dezvoltare software personalizată , de la servicii interne până la API-uri publice de produs cu înrolare în autoservire. Tratăm specificația, documentația și mediul de test ca livrabile, nu ca gânduri de final, pentru că ele decid dacă cineva reușește să se integreze.

Dacă vă aflați pe cealaltă parte a problemei și consumați API-ul altcuiva în loc să publicați unul propriu, ghidul nostru despre integrarea API-urilor terțe arată la ce să fiți atenți. Altfel, spuneți-ne cine sunt consumatorii și ce trebuie să facă, iar noi vom delimita proiectul nivel cu nivel, ca să vedeți exact cât costă fiecare grad de ambiție.

Articole similare: Externalizarea dezvoltarii software catre o companie din , Integrare CRM și ERP: costuri, metode și capcane , Modernizare mainframe: rewrite, refactor sau replatform .

Întrebări frecvente

Cât costă dezvoltarea unui API personalizat? Un API intern costă de regulă între 10.000 și 30.000 de lire sterline, un API pentru parteneri între 40.000 și 100.000, iar un API public de produs peste 100.000. Publicul influențează prețul mult mai mult decât numărul de endpointuri, pentru că un consumator extern cere documentație, mediu de test, versionare și asistență.

Cât durează construirea unui API personalizat? Un serviciu intern durează de obicei între patru și opt săptămâni. Un API de calitate pentru parteneri ia în general trei până la cinci luni, incluzând documentația și un mediu de test. API-urile publice, cu înrolare în autoservire și contorizare la consum, cer frecvent șase luni sau mai mult până la lansare.

Ce face dezvoltarea unui API mai scumpă decât se aștepta? Documentația, mediile de test, limitarea ratei per consumator, suportul pentru versionare și observabilitatea. Acestea apar rar în estimările timpurii și, împreună, reprezintă adesea jumătate din efortul total pentru un API destinat partenerilor sau publicului.

Ar trebui să construiesc un API REST sau GraphQL? REST rămâne alegerea implicită mai sigură pentru API-urile destinate partenerilor și publicului, pentru că uneltele, memorarea în cache și familiaritatea dezvoltatorilor sunt mai răspândite. GraphQL se potrivește uzului intern și aplicațiilor client bogate, dar mută costul în limitele de complexitate a interogărilor și în autorizare.

La ce costuri recurente să mă aștept după lansarea unui API? Alocați anual între cincisprezece și douăzeci și cinci la sută din costul de construcție. Acoperă menținerea versiunilor paralele în perioadele de retragere, timpul de inginerie petrecut răspunzând la întrebări de integrare, întreținerea documentației și monitorizarea necesară consumatorilor externi.