Synchrone Web Services: Ein ausführlicher Überblick
In modernen Anwendungen spielen synchrone Web Services eine zentrale Rolle, da sie eine direkte Kommunikation zwischen Client und Server ermöglichen. In diesem Beitrag werden fünf zentrale Technologien vorgestellt: SOAP, REST, OData, GraphQL und gRPC. Dabei werden wir die jeweiligen Konzepte erläutern und praktische Beispiele sowie Beispielpayloads präsentieren.
1. SOAP (Simple Object Access Protocol)
SOAP ist ein protokollbasierter Ansatz, der stark auf XML und strenge Standards setzt. Es wird häufig in geschäftskritischen Anwendungen eingesetzt, die hohe Anforderungen an Sicherheit und Transaktionsmanagement haben.
Merkmale
- Standardisiert: Nutzt XML für die Nachrichtendefinition.
- Erweiterbar: Unterstützt zusätzliche Sicherheits- und Transaktionsprotokolle.
- Plattformunabhängig: Funktioniert über diverse Transportprotokolle (HTTP, SMTP, JMS).
Beispiel eines SOAP-Payloads
Ein typisches SOAP-Paket wird in einem XML-Format gesendet. Häufig wird das HTTP-Protokoll für die Übertragung genutzt. Im Header werden oftmals Metadata-Informationen mitgegeben, im Body stehen die eigentlichen Daten.
Beispiel einer SOAP-Anfrage
POST /SoapService HTTP/1.1
Host: example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "CreateOrder"
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ex="http://example.com/">
<soapenv:Header/>
<soapenv:Body>
<ex:CreateOrder>
<ex:Order>
<ex:OrderID>12345</ex:OrderID>
<ex:Customer>Max Mustermann</ex:Customer>
<ex:Items>
<ex:Item>
<ex:ProductID>987</ex:ProductID>
<ex:Quantity>2</ex:Quantity>
</ex:Item>
<ex:Item>
<ex:ProductID>654</ex:ProductID>
<ex:Quantity>1</ex:Quantity>
</ex:Item>
</ex:Items>
</ex:Order>
</ex:CreateOrder>
</soapenv:Body>
</soapenv:Envelope>Mögliche Antwort (Response)
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ex="http://example.com/">
<soapenv:Header/>
<soapenv:Body>
<ex:CreateOrderResponse>
<ex:OrderConfirmation>
<ex:OrderID>12345</ex:OrderID>
<ex>Status>Success</ex:Status>
</ex:OrderConfirmation>
</ex:CreateOrderResponse>
</soapenv:Body>
</soapenv:Envelope>2. REST (Representational State Transfer)
REST ist ein Architekturstil, der auf den Prinzipien des Webs basiert und Ressourcen über eindeutige URLs zugänglich macht. Die Kommunikation erfolgt meist über HTTP und nutzt die Standard-HTTP-Methoden.
HTTP-Methoden im Detail
- GET: Ruft Daten von einem Server ab.
- POST: Sendet neue Daten an den Server.
- PUT: Aktualisiert bestehende Daten.
- DELETE: Entfernt Daten vom Server.
Beispiel einer REST API
GET-Anfrage
GET /api/users/123 HTTP/1.1
Host: example.com
Accept: application/jsonAntwort:
{
"userId": 123,
"name": "Max Mustermann",
"email": "max@example.com"
}POST-Anfrage (Erstellen eines neuen Benutzers)
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
{
"name": "Erika Mustermann",
"email": "erika@example.com",
"password": "sicheresPasswort123"
}Antwort:
{
"userId": 124,
"name": "Erika Mustermann",
"email": "erika@example.com"
}PUT-Anfrage (Aktualisieren eines Benutzers)
PUT /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json
{
"name": "Maximilian Mustermann",
"email": "maximilian@example.com"
}Antwort:
{
"userId": 123,
"name": "Maximilian Mustermann",
"email": "maximilian@example.com"
}DELETE-Anfrage (Löschen eines Benutzers)
DELETE /api/users/123 HTTP/1.1
Host: example.comAntwort (Beispiel):
{
"message": "Benutzer 123 wurde erfolgreich gelöscht."
}RESTful Web Services sind ideal, wenn es um einfache, skalierbare und leicht verständliche Schnittstellen geht.
3. OData (Open Data Protocol)
OData erweitert die REST-Architektur um standardisierte Abfrage- und Datenmanipulationsfunktionen. Es wird häufig in datenintensiven Anwendungen verwendet.
Merkmale
- Standardisierte Abfragen: Ermöglicht das Filtern, Sortieren und Paginieren direkt über die URL.
- Interoperabilität: Nutzt HTTP, definiert aber ein festes Datenmodell.
- Erweiterbarkeit: Unterstützt verschiedene Datenquellen.
Beispiel eines OData-Payloads
Abfrage mit Filterung und Paging
GET /odata/Products?$filter=Price gt 50&$orderby=Name&$top=10 HTTP/1.1
Host: example.com
Accept: application/jsonAntwort:
{
"value": [
{
"ProductID": 101,
"Name": "Premium Produkt A",
"Price": 75.0
},
{
"ProductID": 102,
"Name": "Premium Produkt B",
"Price": 80.0
}
// weitere Produkte...
]
}4. GraphQL
GraphQL ist eine Abfragesprache, die es Clients ermöglicht, genau die Daten anzufordern, die benötigt werden. Dadurch wird Overfetching vermieden und die Netzwerklast reduziert.
Merkmale
- Flexible Abfragen: Clients spezifizieren präzise, welche Daten sie benötigen.
- Effiziente Datenübertragung: Minimiert unnötige Datenübertragung.
- Echtzeit-Updates: Unterstützt Abonnements für Echtzeitdaten.
Beispiel einer GraphQL-Abfrage
Abfrage
query {
user(id: "123") {
userId
name
email
orders {
orderId
total
}
}
}Antwort:
{
"data": {
"user": {
"userId": "123",
"name": "Max Mustermann",
"email": "max@example.com",
"orders": [
{
"orderId": "A001",
"total": 150.00
},
{
"orderId": "A002",
"total": 200.00
}
]
}
}
}GraphQL ist besonders nützlich für komplexe Anwendungen, bei denen die Datenstruktur stark variieren kann.
5. gRPC
gRPC ist ein modernes RPC (Remote Procedure Call)-Framework, das von Google entwickelt wurde und auf HTTP/2 basiert. Es ist bekannt für seine hohe Performance und effiziente Datenübertragung.
Merkmale
- Hochperformant: Mehrere Anfragen können parallel über eine einzige HTTP/2-Verbindung übertragen werden.
- Starke Typisierung: Nutzt Protocol Buffers zur Definition der Schnittstellen, was zu einer kompakten und strikten Datenübertragung führt.
- Plattformübergreifend: Unterstützt diverse Programmiersprachen und Betriebssysteme.
Was sind Protocol Buffers (Protobuf)?
Protocol Buffers, oft auch Protobuf genannt, sind ein plattform- und sprachenunabhängiges Verfahren zur Serialisierung strukturierter Daten. Anstatt wie bei JSON oder XML Daten in einem textbasierten Format zu speichern, verwendet Protobuf ein binäres Format, das die folgenden Vorteile mit sich bringt:
- Effiziente Übertragung: Das binäre Format ist kompakt und benötigt weniger Bandbreite.
- Starke Typisierung: Die Struktur der Daten wird in
.proto-Dateien definiert, wodurch sowohl Server als auch Client wissen, welche Felder existieren und welche Datentypen diese Felder aufweisen. - Abwärtskompatibilität: Durch die flexible Versionierung in Protobuf-Dateien können Änderungen (z. B. neue Felder) vorgenommen werden, ohne ältere Clients zu stören.
Beispiel eines gRPC-Service (Protokolldatei in Protocol Buffers)
syntax = "proto3";
package orderservice;
// Definition des Service
service OrderService {
rpc CreateOrder (OrderRequest) returns (OrderResponse);
}
// Nachrichtentypen
message OrderRequest {
int32 orderId = 1;
string customer = 2;
repeated OrderItem items = 3;
}
message OrderItem {
int32 productId = 1;
int32 quantity = 2;
}
message OrderResponse {
bool success = 1;
string message = 2;
}Beispiel eines gRPC-Requests
Anders als bei SOAP oder REST gibt es bei gRPC keinen reinen Text- oder XML-Body, da die Daten binär serialisiert werden. Dennoch kann man den Aufruf prinzipiell folgendermaßen durchführen:
Beispiel mit grpcurl
grpcurl -d '{"orderId": 12345, "customer": "Max Mustermann", "items":[{"productId":987,"quantity":2}]}' \
-plaintext \
localhost:50051 \
orderservice.OrderService/CreateOrderDer Client sendet dabei die OrderRequest-Daten in binärer Form an den CreateOrder-Service, woraufhin der Server eine OrderResponse zurückliefert, z.B.:
{
"success": true,
"message": "Bestellung erfolgreich erstellt"
}In einer Programmiersprache wie Python könnte ein Request beispielsweise so aussehen:
import grpc
import order_service_pb2
import order_service_pb2_grpc
def run():
channel = grpc.insecure_channel('localhost:50051')
stub = order_service_pb2_grpc.OrderServiceStub(channel)
request = order_service_pb2.OrderRequest(
orderId=12345,
customer="Max Mustermann",
items=[
order_service_pb2.OrderItem(productId=987, quantity=2),
order_service_pb2.OrderItem(productId=654, quantity=1),
]
)
response = stub.CreateOrder(request)
print(response)
if __name__ == '__main__':
run()Fazit
Synchrone Web Services ermöglichen eine direkte und unmittelbare Kommunikation zwischen Systemen. Die Wahl der Technologie hängt von den spezifischen Anforderungen des Projekts ab:
- SOAP: Ideal für standardisierte und sicherheitskritische Geschäftsanwendungen.
- REST: Bietet einfache und skalierbare Schnittstellen, wobei HTTP-Methoden (GET, POST, PUT, DELETE) klar definiert sind.
- OData: Ermöglicht erweiterte Abfragefunktionen in datenintensiven Anwendungen.
- GraphQL: Bietet flexible und präzise Datenabfragen, ideal um Overfetching zu vermeiden.
- gRPC: Besticht durch hohe Performance und starke Typisierung, was es zur ersten Wahl in Microservices-Architekturen macht.
Jede dieser Technologien bringt eigene Vor- und Nachteile mit sich, weshalb die Entscheidung stets anhand der Anforderungen, vorhandener Infrastruktur und spezifischer Projektziele getroffen werden sollte.