Leistung

API-Entwicklung

Wir entwickeln APIs, die Ihre bestehenden Systeme verbinden — Webanwendungen, Apps, ERP, CRM, Partner und Datenquellen. Dokumentiert, versioniert und so entworfen, dass der Rest Ihrer Systemlandschaft sicher darauf aufsetzen kann.

Projekt anfragenArbeiten ansehen
Überblick

Was das ist — und was dazugehört.

Eine API stellt die Schnittstellen bereit, über die Webanwendungen, Apps, Partner und angebundene Systeme wie ERP oder CRM miteinander sprechen. Batunet entwirft APIs als langlebige Verträge — versioniert, dokumentiert und stabil, damit alles andere sicher darauf aufsetzen kann.

Leistungsumfang

  • API-Design (REST, GraphQL)
  • Versionierung ohne Brüche
  • Authentifizierung und Rate Limiting
  • Dokumentation und Developer Experience
  • Zuverlässige Webhooks und Ereignisse
Anwendungsfälle

Für welche Vorhaben das passt.

Typische Ausgangslagen, mit denen Unternehmen zu uns kommen — und wo es dazu veröffentlichte Arbeiten gibt.

  1. Fremde Systeme und Datenquellen anbinden

    Partner, Netzwerke oder Dienstleister liefern Daten in eigenen Formaten — per Dateiabruf, REST oder SOAP. Wir binden jede Quelle über einen eigenen Weg an und überführen ihre Daten in ein Modell, das Ihrem System gehört.

    Beispiel aus unseren Arbeiten

  2. Eine API für eigene Oberflächen und Apps

    Website, Verwaltung und App sollen auf dieselbe Fachlogik zugreifen, statt sie jeweils nachzubauen. Eine gemeinsame API hält die Regeln an einer Stelle und trennt Oberfläche und Fachlogik sauber.

    Beispiel aus unseren Arbeiten

  3. Externe Dienste austauschbar halten

    Angebundene Dienste ändern ihre Schnittstellen, ohne zu fragen. Eine eigene Grenze davor fängt Versionswechsel und Fehler ab, damit ein Wechsel nicht bis in Ihren Datenbestand durchschlägt.

    Beispiel aus unseren Arbeiten

  4. Eigene Daten kontrolliert für Partner öffnen

    Kunden oder Partner sollen auf Ihre Daten und Abläufe zugreifen — mit Anmeldung, Rate Limiting und einer Dokumentation, mit der sie ohne Rückfragen arbeiten können. Die Schnittstelle wird dabei zu einem Vertrag, der über Jahre hält.

Einordnung

Wann es passt — und wann nicht.

Wir empfehlen den Weg, der zum Vorhaben passt — auch wenn das ein Standardprodukt ist.

Passt

  • Mehrere Aufrufer teilen dieselbe Geschäftslogik — Frontends, mobile Apps oder Partner. Ab dem zweiten Aufrufer ist die Schnittstelle ein Vertrag, kein Implementierungsdetail.
  • Bestehende Geschäftslogik soll kontrolliert zugänglich werden, ohne fremde Systeme an das Innenleben zu koppeln.
  • Ein externer Dienst soll austauschbar bleiben. Eine eigene Schnittstelle davor trennt das, was bleibt, von dem, was ersetzt wird.
  • Die Schnittstelle soll über Jahre additiv wachsen, ohne die Produktion ihrer Nutzer zu brechen.

Passt nicht

  • Zwei eigene Dienste, die zusammen entwickelt und zusammen ausgerollt werden. Dort ist der Vertrag günstig zu ändern — eine engere Kopplung ist vertretbar.
  • Ein einziger, mitwachsender Nutzer, den man selbst koordiniert. Die volle Strenge aus Vertragsfläche, stabilen Fehlercodes und Deprecation-Prozess lohnt erst bei fremden Aufrufern.
  • Ein Prototyp oder eine kurzlebige Schnittstelle. Dort ist das direkte Spiegeln interner Strukturen die schnellere und richtige Wahl; die Entkopplung lohnt erst, wenn die API lange lebt.
Referenzen

Vergleichbare Arbeiten.

Veröffentlichte Projekte, jeweils mit dem Teil, der bei uns lag. Weitere Referenzen besprechen wir im Gespräch.

Typische Risiken

Risiken, die wir früh erkennen.

Was in Systemen dieser Art typischerweise schiefgeht — und wie wir es vermeiden, bevor es in Produktion sichtbar wird.

  1. Stiller Breaking Change

    Warum
    Ein umbenanntes Feld oder eine nachträglich verschärfte Validierung wirkt wie eine Korrektur. Für den fremden Code am anderen Ende ist es ein Bruch — unabhängig davon, wie klein die Änderung wirkt.
    Frühwarnzeichen
    Änderungen am Bestand statt additiver Erweiterungen; kein automatischer Test gegen den öffentlichen Vertrag; Aufrufer melden den Fehler vor dem eigenen Monitoring.
    Wie wir es verhindern
    Additiv erweitern, wo es geht. Der öffentliche Vertrag wird automatisch getestet, bevor ausgerollt wird; wird eine neue Version nötig, bleibt die alte unberührt gültig.
    Abwägung
    Kosten: Contract-Tests und Zurückhaltung beim Ändern des Bestands. Anders, wenn: die Schnittstelle rein intern ist und mit ihren Aufrufern zusammen ausgerollt wird — dann ist der Vertrag günstig zu ändern.

  2. Fehler ohne Vertrag

    Warum
    Fehler sind Teil des Vertrags, nicht ein Randfall daneben. Wechselnder Fließtext zwingt Aufrufer, auf Formulierungen zu prüfen — und macht die Meldung selbst zum Vertrag.
    Frühwarnzeichen
    Kein stabiler, klassifizierter Code; Client- und Serverfehler nicht unterscheidbar, sodass niemand weiß, ob wiederholt oder korrigiert werden muss; interne Details in Meldungen.
    Wie wir es verhindern
    Stabile, maschinell auswertbare Fehlercodes, eine klare Trennung zwischen Fehler des Aufrufers und Fehler des Anbieters, und keine internen Spuren in der Antwort.
    Abwägung
    Kosten: eine weitere Vertragsfläche, die mit derselben Vorsicht gepflegt wird wie die Erfolgsantworten. Anders, wenn: eine interne Schnittstelle mit einem einzigen, mitwachsenden Nutzer — dort darf das Fehlermodell schlanker bleiben.

  3. Schnittstelle mit der Implementierung verwechselt

    Warum
    Der Anbieter hinter einer Schnittstelle ist austauschbar; die Daten, die durch sie geflossen und geblieben sind, sind es nicht. Wer die eigene Sicht an die Form eines Anbieters bindet, spürt jeden Wechsel bis in den Bestand.
    Frühwarnzeichen
    Das eigene Datenmodell folgt der Struktur eines externen Dienstes; ein Anbieterwechsel wird als Anschlussfrage geplant, nicht als Übersetzung des Bestands.
    Wie wir es verhindern
    Die Daten liegen in einer Form, die dem System gehört; der externe Dienst hängt hinter einer Grenze, die hält.
    Abwägung
    Kosten: eine Übersetzungsschicht und ein geprüft migrierter Bestand statt eines direkten Umschaltens. Anders, wenn: der Bestand klein und unkritisch ist und seine erneute Beschaffung billig wäre.
Vorab zu klären

Fragen, die wir vor der Umsetzung klären.

Ihre Antworten prägen die Architektur stärker als die Wahl der Werkzeuge.

  1. Welche Form hat die Kommunikation — Dinge, Aktionen oder flexible Abfragen?

    Warum das zählt
    Der Stil prägt den Vertrag, und der Vertrag ist schwer zu ändern. Nach Mode zu entscheiden führt eine Passungsfrage als Geschmacksfrage.
    Typische Folge
    Benannte Dinge führen zu REST, Aktionen zwischen bekannten Systemen zu RPC, sehr verschiedene Datenschnitte vieler Aufrufer zu GraphQL. Im Zweifel der verbreitetste Stil, den man in zehn Jahren noch versteht und besetzen kann.

  2. Drückt die Schnittstelle die Fachlichkeit des Aufrufers aus — oder die interne Umsetzung?

    Warum das zählt
    Was ein Nutzer beobachtet, wird zum Vertrag. Gespiegelte interne Strukturen koppeln fremde Systeme an Entscheidungen, die man frei ändern können wollte.
    Typische Folge
    Wir entwerfen die äußere Repräsentation getrennt vom internen Modell und übersetzen an der Grenze. Bei einem Prototyp mit kurzer Lebensdauer entfällt das.

  3. Ändert eine Operation Zustand oder Geld?

    Warum das zählt
    Sobald eine API über ein Netz erreichbar ist, kommt dieselbe Anfrage irgendwann doppelt an. Das ist kein Fehler, sondern eine Eigenschaft verteilter Kommunikation.
    Typische Folge
    Dann wird sie idempotent entworfen: ein eindeutiger Schlüssel pro logischer Operation, geprüft und persistiert in derselben Transaktion wie die Wirkung. Lesevorgänge und natürlich idempotente Operationen brauchen das nicht.

  4. Kann ein bestehender Aufrufer die geplante Änderung bemerken?

    Warum das zählt
    Ist die Antwort ja, ist die Änderung brechend — unabhängig davon, wie klein sie wirkt. Auch eine nachträglich verschärfte Validierung ist ein Bruch.
    Typische Folge
    Wir lösen sie additiv, wo es geht. Wo nicht, entsteht eine neue Version, die alte bleibt unberührt gültig, und die Abschaltung folgt einem angekündigten Deprecation-Prozess statt einem Stichtag.
Projektablauf

Vom ersten Gespräch bis zum laufenden System.

Jedes Projekt folgt denselben vier Schritten. Zwischenstände sehen und prüfen Sie unterwegs, nicht erst am Ende.

  1. 01

    Verstehen und Anforderungen klären

    Im ersten Gespräch mit der Geschäftsführung geht es um die Systeme, die verbunden werden sollen, und darum, wer die Schnittstelle nutzen wird. Wir erfassen Datenflüsse und Fehlerfälle und sagen ehrlich, wie viel Strenge die Schnittstelle braucht.

  2. 02

    Lösung und Architektur planen

    Wir entwerfen den Vertrag: Ressourcen oder Aktionen, Fehlercodes, Authentifizierung, Versionierung. Der Entwurf ist dokumentiert, bevor Code entsteht.

  3. 03

    Entwickeln und gemeinsam prüfen

    Zuerst läuft ein vollständiger Pfad zwischen zwei Systemen, danach folgt die Breite. Automatische Tests prüfen den öffentlichen Vertrag, bevor ausgerollt wird.

  4. 04

    In Betrieb nehmen und weiter betreuen

    Nach dem Start überwachen wir auf Wunsch Aufrufe und Fehler und erweitern die API additiv, ohne bestehende Aufrufer zu brechen.

Wie die Zusammenarbeit im Einzelnen aussieht →
Ergebnis

Was Sie am Ende in der Hand haben.

  • Schnittstellen, die sich weiterentwickeln, ohne zu brechen

  • Ein stabiles Fundament für Partner und weitere Systeme

  • Dokumentation, mit der andere sofort arbeiten können

Eingesetzte Technologien

LaravelSymfonyRESTGraphQLOpenAPI
Fragen

Fragen zu API-Entwicklung

  • REST oder GraphQL?

    REST für stabile, cachebare Ressourcen; GraphQL, wenn Clients sehr unterschiedliche Datenschnitte brauchen. Oft ist REST die richtige, langweilige Wahl.

  • Wie vermeiden Sie Breaking Changes?

    Durch bewusste Versionierung, additive Änderungen und klare Verträge. Eine API ist ein Versprechen an ihre Nutzer.

Weiterlesen

Verwandte Themen.

Leitfäden, Entscheidungen, Leistungen und Arbeiten, die mit dieser Seite zusammenhängen.

Sprechen wir über Ihre Schnittstellen.

Nennen Sie kurz die Systeme, die verbunden werden sollen, oder die API, die entstehen soll — für eigene Anwendungen, Partner oder Datenquellen. Das erste Gespräch führen Sie direkt mit der Geschäftsführung.