EMZETT.SDK
Kurz: Software Development Kit — ein Bündel aus Werkzeugen, Bibliotheken und Dokumentation, um Software für eine bestimmte Plattform oder ein bestimmtes System zu entwickeln.
Genauer: Anders als das JDK (spezifisch für Java) ist “SDK” ein allgemeiner Oberbegriff — es gibt z. B. Android-SDKs, iOS-SDKs oder SDKs für einzelne Cloud-Dienste. Enthält typischerweise APIs, Compiler/Build-Tools, Beispielcode und oft einen Emulator zum Testen.
Im Detail
Ein SDK unterscheidet sich von einer reinen API-Dokumentation dadurch, dass es fertige, direkt nutzbare Werkzeuge mitliefert, nicht nur eine Beschreibung, wie man einen Dienst ansprechen könnte — konkret meist: Client-Bibliotheken in mehreren Programmiersprachen (fertiger Code, um die API bequem aufzurufen, ohne HTTP-Requests von Hand zu bauen), Build- und Debug-Werkzeuge, Beispielprojekte und oft ein Emulator/Simulator, um ohne echtes Zielgerät zu testen (z. B. der Android-Emulator im Android SDK).
Plattform-SDKs (Android SDK, iOS SDK) sind meist verpflichtend, um überhaupt für die jeweilige Plattform zu entwickeln — ohne Android SDK lässt sich keine Android-App bauen. Cloud-Dienst-SDKs (z. B. das SDK eines Zahlungsanbieters oder einer Cloud-Speicher-Plattform) sind dagegen meist optional: die zugrundeliegende API lässt sich auch ohne SDK direkt per HTTP ansprechen, das SDK spart aber Zeit, indem es Authentifizierung, Fehlerbehandlung und Datenformate bereits sauber kapselt.
SDK vs. API vs. Bibliothek
Diese drei Begriffe werden oft durcheinandergeworfen, meinen aber unterschiedliche Dinge: Eine API ist die abstrakte Schnittstelle selbst (eine Vereinbarung, wie man mit einem System kommuniziert — z. B. welche HTTP-Endpunkte existieren). Eine Bibliothek ist wiederverwendbarer Code für eine spezifische Aufgabe (z. B. eine Funktion, die JSON parst). Ein SDK ist ein größeres Bündel, das typischerweise mehrere Bibliotheken, Werkzeuge UND Dokumentation für einen ganzen Entwicklungsbereich zusammenfasst — ein SDK enthält meist mehrere Client-Bibliotheken für verschiedene APIs desselben Anbieters, plus Build-Tools, plus Beispielcode. Man kann eine API also nutzen, ohne ein SDK zu installieren (direkte HTTP-Aufrufe), aber ein SDK bringt fast immer Code mit, der intern APIs aufruft.
Versionsverwaltung und Breaking Changes
SDKs werden regelmäßig aktualisiert, oft mit Breaking Changes zwischen Hauptversionen — eine neue Android-SDK-Version kann z. B. neue Berechtigungsmodelle einführen, die bestehenden Code inkompatibel machen. Größere Anbieter pflegen deshalb parallel mehrere unterstützte SDK-Versionen (“Deprecation Policy”) mit einer angekündigten Frist, bis zu der ältere Versionen noch funktionieren, bevor sie endgültig abgeschaltet werden — für Entwickler bedeutet das, regelmäßig SDK-Updates einzuplanen, statt eine einmal funktionierende Integration dauerhaft unverändert zu lassen.
Beispiel: Stripe-SDK
Ein konkretes Beispiel aus der Praxis: Das Stripe-SDK bündelt Client-Bibliotheken für mehrere Programmiersprachen (Node.js, Python, PHP, Java u. a.), die typsichere Wrapper um die zugrundeliegende REST-API bereitstellen, inklusive automatischer Wiederholungsversuche bei Netzwerkfehlern, sauberer Fehlerobjekte statt roher HTTP-Statuscodes, und Webhook-Signaturprüfung — alles Dinge, die man auch selbst mit rohen HTTP-Requests implementieren könnte, aber deutlich fehleranfälliger und aufwändiger.