APIs – SOAP – REST – HTTP & Demo

SOAP – Der Vorgänger

SOAP (Simple Object Access Protocol) war über viele Jahre hinweg der etablierte Standard für Webservices, bevor modernere Architekturen wie REST populär wurden.

• Verpflichtend: XML als Datenformat
SOAP-Nachrichten müssen immer in XML strukturiert sein.
• Streng, komplex, formal
Klare Regeln und umfangreiche Vorgaben machen SOAP robust, aber weniger flexibel.
• WSDL für Schnittstellenbeschreibung
Über eine WSDL-Datei (Web Services Description Language) wird exakt definiert, welche Funktionen ein Service bereitstellt.
• Gut geeignet für Banken/Unternehmen
Dort werden hohe Anforderungen an Standardisierung, Transaktionssicherheit und Zuverlässigkeit gestellt.
• Sehr sicher, aber schwerfälliger als REST
SOAP bietet starke Sicherheitsmechanismen, ist aber im Vergleich zu REST umfangreicher, langsamer und komplizierter.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                   xmlns:bank="http://bank.example.com">
   <soapenv:Header/>
   <soapenv:Body>
      <bank:getBalance>
         <bank:accountId>12345</bank:accountId>
      </bank:getBalance>
   </soapenv:Body>
</soapenv:Envelope>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <getBalanceResponse>
         <balance>542.30</balance>
      </getBalanceResponse>
   </soapenv:Body>
</soapenv:Envelope>

REST – Moderne APIs

REST (Representational State Transfer) nutzt einfache, einheitliche Standards, um klar zu definieren, wie Clients mit dem Server interagieren – effizient, verständlich und weltweit etabliert.

• Client-Server-Trennung
Klare Aufteilung zwischen Benutzeroberfläche (Client) und Datenverarbeitung (Server).
• Stateless
Jeder Request enthält alle nötigen Informationen; der Server speichert keinen Sitzungszustand.
• Cacheability
Antworten müssen angeben, ob sie cachebar sind, um Performance zu verbessern
• Unitäres Interface
Einheitliche Nutzung von HTTP-Methoden, Statuscodes und Ressourcen-URLs.
• Layered System
Architektur kann aus mehreren Vermittlungsschichten bestehen, ohne dass der Client diese kennen muss.
• Code-on-Demand (optional)
Server kann ausführbaren Code an den Client schicken, um dessen Funktionen zu erweitern.

HTTP-Statuscodes

Diese Codes zeigen den Erfolg oder Fehler einer Anfrage.

fetch()

fetch() ist das moderne, eingebaute Browser-API, um HTTP-Anfragen zu senden. Es arbeitet vollständig asynchron und gibt immer ein Promise zurück, wodurch der Code klar und übersichtlich bleibt.

fetch('/items')
    .then(if(!res.ok) console.error("error while fetching '/items' error: ${res.error}"))
    .then(res => res.json())
    .then(data => console.log(data));

Ablauf

• fetch('/items') => sendet eine Anfrage an den Server.
• .then(res => res.json()) => wandelt die Antwort in JSON-Daten um.
• .then(data => console.log(data)) => verarbeitet die empfangten Daten.