Ce este un SDK?

Dacă API-ul e priza prin care un serviciu poate fi accesat, SDK-ul e trusa de scule livrată împreună cu ea: pachetul oficial — biblioteci de cod, documentație, exemple, unelte — pe care un furnizor de platformă îl dă dezvoltatorilor ca să construiască pe platforma lui repede și corect. Exemplele care ating direct proiectele firmelor: aplicațiile mobile se construiesc cu SDK-urile Apple (iOS) și Google (Android) — de aici și legătura termenului cu discuțiile despre aplicația ta; plățile se integrează cu SDK-urile procesatorilor (Stripe, PayU — care împachetează gata făcute formularele de card, validările, 3DS-ul, în loc ca dezvoltatorul să le construiască din apeluri brute de API), autentificarea cu Google/Facebook, hărțile, notificările, analytics-ul — toate vin ca SDK-uri care se „montează” în aplicație. Relația cu API-ul, sursa clasică de confuzie: API-ul e contractul de comunicare (ce poți cere serviciului), SDK-ul e implementarea lui confortabilă într-un limbaj anume — poți folosi un API și fără SDK (apeluri directe), dar SDK-ul oficial economisește timp și greșeli; practic, „au SDK pentru platforma noastră?” e una dintre întrebările care decid cât costă o integrare. Unghiul mai puțin discutat, dar relevant pentru un beneficiar: fiecare SDK montat în aplicația ta e cod străin care rulează cu drepturile aplicației tale — SDK-urile de analytics și reclame au fost istoric vehiculul prin care aplicații altfel oneste au scurs date de utilizatori (cu consecințe GDPR pentru proprietarul aplicației, adică pentru tine), iar SDK-urile neactualizate cară vulnerabilități. De aici două întrebări legitime la recepția oricărei aplicații: ce SDK-uri terțe conține și de ce fiecare (inventarul — o pagină), și cine le ține la zi (mentenanța — pentru că platformele le actualizează constant, iar magazinele de aplicații resping la un moment dat versiunile antice).