Was ist ein Webdienst?

Ein Webdienst ist eine Schnittstelle, über die Anwendungen Daten austauschen oder Funktionen über ein Netzwerk aufrufen. Eine Website ist in erster Linie für Menschen gedacht, die sie lesen und bedienen; ein Webdienst stellt dagegen einen Vertrag für Software-Clients bereit. Ein Produkt kann beides anbieten. Viele Dienste setzen auf HTTP und JSON, der Begriff umfasst aber auch andere Protokolle und Datenformate.

Wie Anfrage und Antwort ablaufen

Ein Client schickt eine Anfrage an einen festgelegten Endpunkt – mit Methode, Parametern und, falls nötig, Zugangsdaten. Der Dienst prüft die Anfrage, führt die Operation aus und sendet eine Antwort zurück. Bei HTTP-APIs unterscheiden Statuscodes die groben Ergebnisse: eine erfolgreiche Antwort, ein Problem auf Clientseite wie ungültige Eingaben oder einen Fehler auf dem Server. Genauere Angaben liefert meist der Antworttext in einem dokumentierten Format.

Ein klarer Vertrag beschreibt Pfade, Methoden, Felder, Typen, Authentifizierung, Ratenbegrenzungen und Fehlerfälle. So lassen sich Clients unabhängig entwickeln. Versionierung ist wichtig: Ändert sich ein Feld oder seine Bedeutung, können bestehende Anwendungen ausfallen, selbst wenn die Adresse des Endpunkts gleich bleibt. Halten Sie zugesagte Abwärtskompatibilität ein und nennen Sie rechtzeitig Fristen, bevor Sie Funktionen abschalten.

Gängige Schnittstellenstile

REST ist ein Architekturstil, kein einzelnes Übertragungsformat. Als RESTful bezeichnete HTTP-APIs bilden Ressourcen meist über URLs ab und nutzen Methoden wie GET zum Lesen sowie POST oder PUT für Änderungen. Ein GET sollte keinen dauerhaften Zustand verändern, denn Clients und Zwischenstationen dürfen ihn wiederholen oder zwischenspeichern. SOAP arbeitet mit strukturierten XML-Nachrichten und formalen Dienstbeschreibungen und ist in vielen Unternehmenssystemen verbreitet.

Mit GraphQL fordern Clients über ein Schema gezielt bestimmte Felder an, oft über HTTP. Das spart unnötige Datenübertragung, bringt aber zusätzliche Komplexität bei Abfragekosten, Autorisierung und Caching. Webhooks kehren das übliche Polling um: Ein Dienst ruft bei einem Ereignis einen registrierten Endpunkt auf. Webhooks brauchen eine Authentifizierung des Absenders, eine Behandlung von Wiederholungen und Schutz vor doppelter Zustellung. Keiner dieser Ansätze ist grundsätzlich der beste.

Sicherheit und Datenschutz

Schützen Sie Daten bei der Übertragung mit HTTPS und prüfen Sie das Serverzertifikat. Authentifizieren Sie Aufrufer mit einem passenden Verfahren und autorisieren Sie jede Operation und jedes Objekt einzeln. Ein gültiges Token belegt nur das, was sein Geltungsbereich erlaubt; beliebige Eingaben werden dadurch nicht sicher. Prüfen Sie Größe und Typen der Anfragen, geben Sie in Fehlermeldungen keine privaten Daten preis und setzen Sie Limits gegen Missbrauch.

Geheimnisse gehören nicht in öffentliche URLs, clientseitigen Quellcode oder Protokolle. Tauschen Sie offengelegte Zugangsdaten aus, beschränken Sie ihren Geltungsbereich und trennen Sie Zugangsdaten für Produktion und Tests. Akzeptiert eine API eine Callback-URL, prüfen Sie die Ziele, damit keine Anfragen in interne Netze gelangen. Dokumentieren Sie, welche personenbezogenen Daten zurückgegeben werden, und speichern Sie nur, was nötig ist.

Zuverlässigkeit und Leistung

Netzwerke fallen aus, daher brauchen Clients Timeouts, begrenzte Wiederholungsversuche und eine klare Behandlung von Teilfehlern. Eine Leseanfrage darf wiederholt werden, wenn das gefahrlos möglich ist; wer eine Zahlung oder eine andere Änderung wiederholt, braucht ein idempotentes Design, um Duplikate zu vermeiden. Paginierung begrenzt große Ergebnismengen. Caching entlastet den Dienst bei stabilen öffentlichen Daten, schnell veränderliche oder private Antworten erfordern dagegen eine sorgfältige Cache-Richtlinie.

Betreiber sollten Latenz, Fehlerraten und Verfügbarkeit auf dem tatsächlichen Weg der Clients messen. Auch ein Server, der HTTP 200 zurückgibt, kann unvollständige oder unbrauchbare Daten liefern – überwachen Sie also auch die erwarteten fachlichen Ergebnisse. Ratenbegrenzungen schützen einen Dienst, sollten aber vorhersehbar kommuniziert werden. Ist der Dienst für Nutzer wichtig, stellen Sie für Störungen eine Statusseite oder einen Support-Kanal bereit.

Einen Dienst auswählen oder entwickeln

Gehen Sie von der Aufgabe des Nutzers und dem Datenvertrag aus und wählen Sie dann einen Schnittstellenstil, den Clients umsetzen und das Team pflegen kann. Testen Sie normale Antworten, fehlerhafte Eingaben, abgelaufene Zugangsdaten, Berechtigungen, Paginierung und Timeouts. Halten Sie Beispiele aktuell und zeigen Sie konkrete Fehler. Lesen Sie bei der Einbindung eines Drittanbieterdienstes dessen Nutzungsgrenzen, Datenrichtlinie und Änderungsankündigungen; auch ein bequemer Endpunkt bleibt eine Abhängigkeit, die ausfallen kann.