Dieser Beitrag bietet einen sehr kompakten Überblick über die Protokolle, die Sie kennen sollten, wenn Sie aktiv Webanwendungen entwickeln. Die Informationen in diesem Kapitel sind grob in folgende Abschnitte unterteilt:

  • Das OSI-Referenzmodell
  • Die Internet-Protokollfamilie mit TCP/IP und DNS
  • Hypertext Transfer Protokoll (HTTP)
  • Representational State Transfer (REST)

Standardisierung mit RFCs

Wenn Sie sich mit Protokollen und konkreten Implementierungen technischer Verfahren rund um das Internet beschäftigen, werden Sie immer wieder mit RFCs (Request for Comments) konfrontiert. Die RFCs dienen als öffentliches Diskussionsforum für technische und organisatorische Fragen des Internets. Sie wurden mit dem ARPA-NET im Jahre 1969 ins Leben gerufen. Die RFC 0001 wurde am 7. April 1969 veröffentlicht, noch während der laufenden Entwicklung des ARPANET.

RFCs werden fortlaufend nummeriert und können verschiedene Stufen durchlaufen. Es gibt keine Versionsnummern. Wird ein RFC umfassend weiterentwickelt, erscheint ein neues Dokument mit einer neuen Nummer. Das alte wird als obsolet gekennzeichnet. Werden aus RFCs Standards verabschiedet, so erscheinen diese in einer zweiten Dokumentform, die durch STD gekennzeichnet ist. Der Zusammenhang zwischen RFCs und STDs ist in RFC 2500 geregelt. Der Standardisierungsprozess wird in RFC 2026 erläutert.

Als gute Informationsquelle für RFCs ist die folgende Webseite zu empfehlen:

Hier können Sie in der RFC- und STD-Datenbank komfortabel stöbern. Wenn Sie nach tiefergehenden Informationen zu bestimmten Protokollen wie beispielsweise ICMP oder DNS suchen, tragen Sie diese in die Suchmaske ein.

Eine gute Informationsquelle ist der RFC-Editor
Eine gute Informationsquelle ist der RFC-Editor

Amüsant kann das Studium von RFCs mit dem Erscheinungsdatum vom 1. April und dem Status INFORMATIONAL sein. Zu empfehlen ist hier beispielsweise RFC 2550, in welchem die Jahr 10.000-Problematik erörtert wird.

Das OSI-Referenzmodell

Für die Entwicklung und Bewertung von Kommunikationsprozessen wird in der IT-Welt häufig zum ISO/OSI-Referenzmodell Bezug genommen. Dieses Modell wurde im Jahre 1984 von der ISO (International Organization for Standardization) verabschiedet und beschreibt alle wesentlichen Prozesse bei der IT-gestützten Datenübertragung über ein Schichtenmodell. Komplett ausgeschrieben steht die Abkürzung ISO/OSI übrigens für Reference Model for Open Systems Interconnection of the International Organization for Standardization.

Die folgende Tabelle zeigt die sieben Schichten des ISO/OSI-Referenzmodells und ihre Bedeutungen.

Nr. Bezeichnung Aufgabe bzw. Beispielanwendungen
7 Anwendung Nutzerschnittstelle Programmschnittstelle
6 Darstellung Kodierung und Dekodierung
5 Sitzung Kommunikationssteuerung
4 Transport Aufbau von Verbindungen Datentransport
3 Vermittlung Adressierung und Routing von Datenpaketen
2 Sicherung, Logical Link Control Kontrollfunktionen, Datenfragmentierung
MAC (Media Access Control)
1 Bitübertragung Physikalischer Netzwerktransport (Kabel, Funk etc.)

Bei einem genau nach diesem Modell entwickelten Übertragungsverfahren arbeitet auf jeder Ebene genau eine Komponente beziehungsweise ein Netzwerkprotokoll. Zwischen zwei Computersystemen werden dann jeweils alle Schichten durchlaufen. Der eigentliche Datenaustausch findet schließlich nur über die Schicht 1, beispielsweise das Netzwerkkabel, statt. Die einzelnen Schichten innerhalb eines Partners „kommunizieren“ damit jeweils nur mit den direkt darüber und darunter liegenden Nachbarn über die Protokolle und technischen Komponenten. Dadurch sind die höheren Schichten unabhängig von den Prozessen, die sich weiter unten abspielen. Ob die Schicht 1 technisch über ein Kupfer- oder ein Glasfaserkabel implementiert ist, ist für die Protokollschicht, die kontrolliert Datenpakete versenden will, irrelevant.

Das ISO/OSI-Referenzmodell ist ein wenig theoretisch und wird in der Praxis selten konsequent umgesetzt. Das beste Beispiel dafür sind die am meisten verbreitete Netzwerkprotokolle TCP und IP. Die Entwicklung dieser Protokolle ist älter als das Referenzmodell, sodass sich die sogenannte Internet-Protokollfamilie nur teilweise darin abbilden lässt. Die Motivation für die Entwicklung einer eigenständigen Standardisierungsschicht war die notwendige Vereinfachung und damit Verringerung des Implementierungsaufwands.

Die Internet-Protokollfamilie

Die Internet-Protokollfamilie (Internet Protocol Suite, IPS) kann in vier Schichten eingeteilt werden, die ähnlich wie die des Referenzmodells strukturiert sind. Ab Schicht 2 übernehmen verschiedene Protokolle jeweils spezifische Aufgaben. Diese werden in den nächsten Abschnitten noch näher vorgestellt.

Internet-Protokollfamilie im Vergleich zum ISO/OSI-Referenzmodell
Internet-Protokollfamilie im Vergleich zum ISO/OSI-Referenzmodell

Wichtige Protokolle der Internet Protocol Suite

Nachfolgend werden die wichtigsten Protokolle der IPS vorgestellt. Die Reihenfolge entspricht dabei der im IPS-4-Schichtenmodell (siehe Abbildung).

In der Abbildung unten sind die nochmals die wichtigsten Protokolle und ihre Einordnung in das TCP/IP Schichtenmodell sowie in das OSI-Schichtenmodell dargestellt.

Der IPS-Stack
Der IPS-Stack

Eine besondere Rolle kommt dabei dem ARP-Protokoll zu. Da dieses sich zwar rein technisch über dem DLCMAC (Ethernet) befindet, aber nicht zu Schicht 3 gehört, wird es manchmal auch als Schicht 2,5-Protokoll bezeichnet.

Address Resolution Protocol (ARP)

Über dieses Protokoll, welches auf einer sehr elementaren Ebene arbeitet, erfolgt die Zuordnung von IP-Adressen zu den physischen MAC-Adressen der Netzwerkadapter der beteiligten Kommunikationsteilnehmer. MAC steht für Media Access Control. MAC-Adressen sind stets weltweit eindeutig, sodass eine Verwechslung von Teilnehmern an dieser Stelle ausgeschlossen werden kann. Allerdings gibt es Netzwerkadapter, die das Eingeben einer benutzerdefinierten MAC-Adresse zulassen.

Die Informationen zu den MAC-Adressen der beteiligten Netzwerkcomputer werden bei Windows Server 2003/2008, wie bei anderen Betriebssystemen auch, in einem ARP-Cache gehalten. Damit müssen diese nicht immer wieder neu ermittelt werden. Den ARP-Cache können Sie über die Eingabeaufforderung mit dem Kommando arp (Linux und Windows nutzen dasselbe Kommando) und der Option –a anzeigen lassen:

$ arp -a

Haben Sie mehrere Netzwerkadapter in Ihrem Computersystem installiert, können Sie den ARP-Cache für einen bestimmten Adapter abfragen, indem Sie dessen IP-Adresse angeben:

$ arp –a 192.168.100.6

Welche und wie lange Daten in diesem Cache gehalten werden, können Sie anpassen. Dies ist in der Praxis allerdings kaum notwendig. Eine genaue Syntaxbeschreibung zum Programm arp finden Sie in der Online-Hilfe zu Windows Server oder der entsprechenden Manpage.

Internet Control Messaging Protocol (ICMP)

Dieses Protokoll dient vor allem zum Transport von Diagnose-, Kontroll- und Routingdatenpaketen im Netzwerk. Es befindet sich wie das Internet Protocol (IP) auf Schicht 2 des IPS-Schichtenmodells. ICMP wird beispielsweise vom Dienstprogramm ping benutzt, um Informationen von einem Host zu erfragen.

Ping auf einen Server (Windows-Kommandozeile)
Ping auf einen Server (Windows-Kommandozeile)

Der Server in der Abbildung ist keine Fake-Adresse. Es handelt sich um den DNS-Server von Google (google-public-dns-a.google.com).

Internet Protocol (IP)

IP dient zum eigentlichen Transport der Nutzdaten im Netzwerk. Das Protokoll zeichnet sich durch folgende Merkmale aus:

  • IP-Adressierung: Jeder Netzwerkknoten kann durch eine eindeutige Adresse, die IP-Adresse, direkt erreicht werden. Die Unterteilung zwischen dem Teilnetzwerk und der konkreten Hostadresse wird mit Hilfe von Subnetzmasken vorgenommen.
  • Keine Fehlerkorrektur: Über IP werden die Daten zwar transportiert, es erfolgt allerdings keine Fehlerkorrektur.
  • IP-Fragmentierung: Datenpakete können bei Bedarf über IP in kleinere Einheiten zerlegt werden, wenn beteiligte Netzwerkgeräte auf bestimmte Paketgrößen limitiert sind.
  • IP-Broadcast: Datenpakete können mit IP an einen ganz bestimmten Host geschickt werden, indem dessen IP-Adresse verwendet wird. Dies wird Unicast genannt. Über eine entsprechende Adressierung können aber mehrere Hosts auf einmal angesprochen werden. Dies wird mit Multicast bezeichnet und kommt dann zum Einsatz, wenn nicht sitzungsorientiert Daten ausgetauscht werden. Das können beispielsweise UDP- oder ICMP-Datenpakete sein. Ein UDP-(Multimedia-)-Datenstrom kann so an mehrere Empfänger gleichzeitig gesendet werden.
  • IP-Routing: IP ist ein routingfähiges Protokoll. Das bedeutet, dass der IP-Datenstrom gezielt über IP-Router in voneinander sonst getrennte Teilnetzwerke geleitet werden kann.

Da IP zu den wichtigeren Protokollen im Web gehört, soll an dieser Stelle etwas genauer auf die Zusammensetzung des Kopfes (Headers) eingegangen werden.

IP-Header
IP-Header
  • TOS
    Neben der Version wird die Länge des IP-Kopfes (IP Header Length — IHL) und der Diensttyp angegeben. Auf diese Weise können Geräte den Verkehr anhand der Art der Daten (Type of Service (TOS), eine Art der Priorisierung) priorisieren.
  • Fragmentierung
    Ferner werden noch die gesamte Paketlänge sowie die Felder Identification (hilft bei der Erkennung von Fragmenten), Flags (gibt Auskunft, ob das Paket fragmentiert ist) und das FragmentationOffset für das Zusammensetzen fragmentierter Pakete angegeben.
  • Adressen
    Die wichtigsten zwei Felder stellen die Quelle (Source) sowie die Ziel (Destination) der Adresse dar. Hier wird die IP Adresse byteweise als 32 Bit (= 4 Byte) Wert abgelegt.
  • Options und Protocol
    Des Weiteren werden die Felder Options (Informationen für Router), Time To Live (Anzahl der Vermittlungsstellen, über die ein Paket übermittelt wird), Protocol (welches Protokoll sich innerhalb des IP Paketes befindet, TCP = 6 oder UDP = 17) sowie eine Checksumme übermittelt, um Fehler im Kopf zu erkennen.

Keine Fehlerkorrektur

Eine Fehlerkorrektur ist im IP selbst nicht vorgesehen. Diese muss über ein Protokoll erfolgen, welches eine Schicht darüber angesiedelt ist. Dies ist beispielsweise das Transmission Control Protocol (TCP). TCP-Datenpakete werden dazu in IP-Pakete „verpackt“. Am Zielsystem erfolgt die Überprüfung der TCP-Pakete. Bei Fehlern können damit die Daten erneut angefordert werden. Aus diesem Grund spricht man bei IP auch von einem Transportprotokoll, wogegen TCP ein Absicherungsprotokoll ist.

IP-Fragmentierung
IP-Fragmentierung
  • MTU
    : Die maximale IP-Paketgröße wird mit Maximum Transmission Unit (MTU) bezeichnet. Ist die Paketgröße kleiner oder gleich der MTU, muss das Paket nicht zerlegt, sondern fragmentiert werden. Fragmentierte IP-Pakete sind durch ein gesetztes Flag gekennzeichnet und werden über eine entsprechende Nummerierung am Zielsystem wieder zusammengesetzt. Allerdings birgt die IP-Fragmentierung ein potenzielles Sicherheitsrisiko. Geschickte Hacker können beispielsweise IP-Fragmente so bilden, dass sie beim Zusammensetzen das Zielsystem zum Absturz bringen. Deshalb werden IP-Fragmente durch moderne Firewalls in der Standardeinstellung abgewiesen. Die IP-Fragmentierung wird heute meist durch das Verfahren Path MTU Discovery vermieden. Dabei handeln die beteiligten Systeme die MTU-Größe untereinander aus.

IPV6 vs V4

Zwar ist das IP Protokoll in der Version 6 bereits seit langem spezifiziert, jedoch kommt es nur sehr schwer in Gang. Das mag zum Teil an den Providern und zum Teil an den Herstellern von IP-Equipment liegen. Aus diesem Grund steht IPv4 hier im Vordergrund.

Transmission Control Protocol (TCP)

TCP ist eine Schicht über IP angesiedelt und verfügt gegenüber diesem über einen wirksamen Mechanismus zur Fehlerkorrektur. Neben einer Nummerierung der Datenpakete werden Prüfsummen generiert, mit deren Hilfe die Integrität der Daten sichergestellt wird. Wird ein Fehler erkannt, erfolgt automatisch eine Anforderung des bzw. der defekten Datenpakete, das Gleiche gilt für den Fall, dass ein Paket bis zum Ablauf einer bestimmten Zeit nicht eingetroffen ist. Auch diese Daten werden neu angefordert.

Da jede Leitung unterschiedliche qualitative Eigenschaften hat, kann TCP die Parameter, wann ein Paket zu wiederholen ist, dynamisch anpassen. Auf diese Weise wird immer eine optimale Performance garantiert.

TCP-Header
TCP-Header
  • Sequence Number
    : Die Sequence Number ist eine fortlaufende Nummer, welche ein Paket in dem Datenstrom kennzeichnet. Mit ihrer Hilfe können Pakete, welche in der falschen Rei-henfolge eintreffen, wieder sortiert werden.
  • Acknowledge Number
    : Die Acknowledge Number wird verwendet, um der Gegenstelle mitzuteilen, bis zum wievielten Datenpaket alle Daten erfolgreich eingetroffen sind. Auf diese Weise kann indirekt eine Neuübertragung ausgelöst werden, wenn beispielsweise nur bis zum vorletzten Paket bestätigt wurde. Der Sender wartet noch, ob das Paket etwas verspätet bestätigt wird (Timeout). Ist das nicht der Fall, werden in der Regel alle Pakete ab dem nicht empfangenen Pakt nochmals übertragen.
  • Window
    : Window ist die Anzahl der Daten-Oktetts (Bytes), beginnend bei dem durch das Acknowledgment-Feld indizierten Daten-Oktett, die der Sender dieses TCP-Paketes bereit ist zu empfangen.

Port

Zusätzlich zu den IP-Quell- und Zieladressen verwendet TCP sogenannte Portnummern. Diese ergeben zusammen mit den IP-Adressen eine eindeutige Verbindung. Jeder Dienst bekommt einen Port zugewiesen, auf dem dieser eingehende Verbindungen entgegennimmt. Da viele Standarddienste immer die gleichen Ports verwenden, werden Ports oft nach den jeweiligen Diensten benannt. Beispiele:

  • Port 23: Telnet
  • Port 80: HTTP-Standard
  • Port 21: FTP

Datenstrom

TCP ist ein Datenstrom-Protokoll (stream oriented), man spricht auch von einem verbindungsorientierten Protokoll. Das bedeutet, es werden zwar einzelne Datenpakete gesendet, jedoch gibt es eine Verbindung, welche vor der Datenübertragung aufgebaut und danach wieder abgebaut wird, ganz im Gegenteil zu UDP.

Auf weitere Felder soll in diesem Zusammenhang nicht weiter eingegangen werden, da sich mit diesem Thema allein ein Buch füllen ließe. Das TCP-Protokoll ist das meistgenutzte dieser Schicht und dient zum verbindungsorientierten Datentransfer zwischen zwei Hosts.

User Datagram Protocol (UDP)

Dieses Protokoll ist verwandt mit TCP. Es unterscheidet sich allerdings in wichtigen Parametern und dient anderen Zwecken. So ist keine Fehlerkorrektur implementiert. Dies ist nicht für alle Arten von Datentransfers notwendig. Multimedia-Streams werden beispielsweise meist mit UDP übertragen, da es hier vor allem auf eine hohe Performance ankommt. Wenn bei bewegten Bildern einige Frames fehlen, fällt dies nicht unbedingt ins Gewicht. Wichtiger ist dann, dass die Information selbst übertragen wird, also der Inhalt des Films beim Empfänger ankommt. Andauerndes Stocken bei der Übertragung, weil fehlerhafte oder unvollständige Daten neu übertragen werden müssen, stört da mehr.

Multimedia und VoIP

UDP kommt standardmäßig bei der Abfrage von DNS-Informationen zum Einsatz. Hier bringt das Protokoll bei den zahlreichen kleinen Datenpaketen, die einen DNS-Server ständig erreichen, einen Performance-Vorteil. Weitere Anwendungen für dieses Protokoll sind Routingprotokolle wie RIP (Routing Information Protocol), TFTP (Trivial File Transfer Protocol) oder SNMP (Simple Network Management Protocol). Aber auch bei Multimedia und anderen Streaming Anwendungen wie VoIP kommt UDP zum Einsatz.

Zu beachten ist, dass UDP aufgrund der fehlenden Flusskontrolle und Fehlerkorrektur als nicht sehr sicheres Protokoll gilt. Deshalb ist es ein beliebtes Protokoll für Hacker, die beispielsweise mit Denial of Service-Attacken immer wieder von sich reden gemacht haben. Dabei werden Hosts mit einer Unmenge von UDP-Paketen überflutet, was zu deren Überforderung und damit der zeitweisen Lahmlegung führt.

Session Initiation Protocol (SIP)

VoIP (Voice over IP) nimmt weiter an Bedeutung zu. Auch wenn dieses Buch nicht über Multimedia und Telefonie handelt, darf dieses Protokoll in der Aufzählung der wichtigsten Internetprotokolle nicht fehlen. Wie der Name schon zum Ausdruck bringt, wird dieses Protokoll zum Aufbau und der Steuerung von Kommunikationssession aller Art verwendet. Weitere Informationen finden Sie im RFC 3261.

Die Hochsprachenprotokolle

Die Hochsprachenprotokolle arbeiten auf Schicht 7 des Referenzmodells bzw. Schicht 4 der IPS. Sie sind in der Regel textbasiert und übermitteln einfache Kommandos. Für die Arbeit mit Web-Anwendungen ist das Hypertext Transfer Protocol HTTP ausnahmslos das Wichtigste. Wichtig sind daneben auch das File Transfer Protocol FTP, das Network News Transfer Protocol NNTP und das Simple Mail Transfer Protocol SMTP, die nachfolgend im Überblick vorgestellt werden.

File Transfer Protocol (FTP)

Neben HTTP ist dieses Protokoll das Wichtigste beim tagtäglichen Einsatz im Internet. Es dient dem Datenaustausch zwischen FTP-Server und -Client, wobei der Client auf eine genau definierte Art und Weise Zugriff auf das Dateisystem des Servers erhalten kann.

Für den Zugriff auf einen FTP-Server bieten alle modernen Betriebssysteme verschiedene Arten von Clients. Dazu kommen viele grafische FTP-Clients.

Network News Transfer Protocol (NNTP)

Dieses Protokoll dient zum Nachrichtenaustausch zwischen sogenannten News-Servern und entsprechenden Clients. Es ist historisch gesehen eines der ältesten Protokolle, welches noch weit vor dem Einzug des Internets in den Alltag genutzt wurde. Das Protokoll arbeitet, anders als HTTP, nicht statuslos, sondern führt einen Message Pointer. Für die Kommunikation mit einem News-Server ist eine Anmeldung erforderlich.

Das Protokoll gilt inzwischen als veraltet. Nachrichtengruppen werden zunehmen durch Web-basierte Foren verdrängt, die mehr Gestaltungsspielraum ermöglichen.

Simple Mail Transfer Protocol (SMTP) / Extended SMTP (ESMTP)

SMTP kommt sogar an Clientsystemen für das Versenden sowie bei Mailservern zum Senden und Weiterleiten von E-Mails zum Einsatz. Inzwischen hat sich der ESMTP-Standard durchgesetzt. Dieser ist in RFC 2821 spezifiziert und bietet erweiterte Funktionen zur Kommunikation zwischen SMTP-Client und -Server.

Wie viele Protokolle im Web-Umfeld ist auch diese Protokoll ASCII-Text basiert. Alle Nachrichten, welche vom Client zum Server gesendet werden, können dabei sowohl vom Menschen als auch von der Software interpretiert werden.

Hypertext Transfer Protocol (HTTP)

In diesem Abschnitt erfahren Sie das Wichtigste über HTTP, das in der Webserver-Programmierung die herausragende Rolle spielt.

HTTP dient der Kommunikation mit Webservern. Es gibt die Versionen 1.0 (1996, RFC 1945), 1.1 (1999, RFC 2616) und 2.0 (2015, RFC 7540). Auf Seiten der Browser wird HTTP 1.1 gesprochen, einige neuere (Chrome, Edge) kennen bereits HTTP 2.0. Die Version 2.0 befindet sich heute (2015 / 2016) in der Einführungsphase. Dazu kommen eine Reihe von Sub-Standards, die teilweise implizit benutzt werden:

  • RFC 7541 Header Compression (2, 2015)
  • RFC 7230 Message Syntax and Routing (1.1, 2014)
  • RFC 7231 Semantics and Content (1.1, 2014)
  • RFC 7232 Conditional Requests (1.1, 2014)
  • RFC 7233 Range Requests (1.1, 2014)
  • RFC 7234 Caching (1.1, 2014)
  • RFC 7235 Authentication (1.1, 2014)

Bei HTTP handelt es sich um ein verbindungs- oder statusloses Protokoll. Server und Client nehmen also nie einen besonderen Zustand ein, sondern beenden nach jedem Kommando den Prozess vollständig, entweder mit Erfolg oder mit einer Fehlermeldung. Es obliegt dem Kommunikationspartner, darauf in angemessener Weise zu reagieren.

Protokollaufbau, Header, Body

HTTP-Kommandos werden als ASCII-Text übertragen und können aus mehreren Zeilen bestehen. Die erste Zeile ist immer die Kommandozeile. Daran angehängt kann ein sogenannter Message-Header (Nachrichtenkopf) folgen. Der Nachrichtenkopf enthält weitere sogenannten Kopffelder, die das Kommando näher beschreiben. So kann ein Content-Length-Kopffeld enthalten sein. Steht dort ein Wert größer als 0, folgen dem Nachrichtenkopf Daten. Die Daten werden also gleich zusammen mit dem Kommando gesendet, man spricht dann vom Body (Nachrichtenkörper) der Nachricht. HTTP versteht im Gegensatz zu anderen Protokollen den Umgang mit 8-Bit-Werten. Binärdaten, wie Bilder oder Sounds, müssen nicht konvertiert werden. Folgen dem HTTP-Kommando und den Nachrichtenkopf-Zeilen zwei Leerzeilen (Zeilenwechsel), so gilt das Kommando als beendet. Kommandos mit Nachrichtenkörper haben kein spezielles Ende-Zeichen. Das Content-Length-Kopffeld bestimmt, wie viele Bytes als Inhalt der Nachricht betrachtet werden.

Kommandoaufbau

Ein HTTP-Kommando hat immer folgenden Aufbau:

METHODE ID VERSION

Als METHODE wird das Kommando selbst bezeichnet.

Methode oder Verb?

In der Literatur wird die HTTP-Methode manchmal als „Verb“ bezeichnet. Der Begriff Verb kommt jedoch in der RFC und allen Standardardisierungsdokumenten nicht vor. Die Ursache liegt in der Bezeichnung einiger Klassen und Datentypen in den Entwicklungsumgebungen von Microsoft, wo Methoden als HTTP-Verben bezeichnet werden (siehe Link).

Die folgende Tabelle zeigt die wichtigsten HTTP-Methoden auf einen Blick.

Methode Bedeutung
CONNECT Verbindung zu einer TLS-Ressource aufbauen
DELETE Ressource löschen (siehe REST)
GET Ressource anfordern
HEAD Header der Ressource anfordern
LINK Verknüpfung zweier Ressourcen beantragen
OPTIONS Merkmale des Webservers erfragen
POST Formulardaten an einen Serverprozess senden
PUT Ressource auf dem Webserver ablegen (siehe REST)
TRACE Kommando zurückschicken lassen
UNLINK Verknüpfung zwischen Ressourcen löschen

Beachten Sie, dass die Methode unbedingt in Großbuchstaben geschrieben werden müssen, exakt wie in der Tabelle oben gezeigt. Als Ressource werden all die Objekte bezeichnet, die übertragen werden können — in erster Linie also HTML-Dateien und Bilder.

Die ID einer Ressource kann beispielsweise eine Adresse oder ein Dateiname sein:

GET index.html HTTP/1.0

Dieses Kommando fordert die Datei index.html an.

Die HTTP-Statuscodes

Die Antwort auf ein Kommando besteht im Senden der Daten – wenn dies gefordert wurde – und einem Statuscode. Dem Statuscode folgen optionale Felder und, bei der Übertragung von Ressourcen, die Daten. Die Statuszeile hat folgenden Aufbau:

VERSION STATUSCODE STATUSTEXT

Der Statuscode ist eine dreistellige Zahl, von der die erste Ziffer (Hunderterstelle) die Zuordnung zu einer bestimmten Gruppe anzeigt.

Gruppe Code Name Bedeutung
1 100 Continue Weiter fortfahren
1 101 Switching Protocols Protokollwechsel erforderlich, z.B.
von HTTP auf WebSockets
1 102 Processing Server bearbeitet die Anfrage, verhindert ggf.
Timeout bei längere Verarbeitungszeit
2 200 OK Kommando erfolgreich (nach GET/POST)
2 201 Created Ressource wurde erstellt (nach PUT)
2 202 Accepted Authentifizierung akzeptiert (nach GET)
2 204 No Content Kein Inhalt oder nicht angefordert (GET)
3 301 Moved Permanently Ressource am anderen Ort
3 302 Found Ressource zeitweilig an anderem Ort
(dies ist ein temporärer Zustand)
3 304 Not Modified Ressource wurde nicht verändert (steuert Proxy)
4 400 Bad Request Syntaxfehler (alle Kommandos)
4 401 Unauthorized Keine Autorisierung
4 403 Forbidden Nicht öffentlicher Bereich, Anfrage unzulässig
4 404 Not Found Ressource nicht gefunden
5 500 Server Error Serverfehler, Fehlfunktion der
Serversoftware oder -applikation
5 503 Service Unavailable Dienst nicht verfügbar

Sie werden den Fehler 404 sicher kennen. Kennenlernen werden Sie auch den Fehler Nummer 500, der erzeugt wird, wenn ein Programm nicht funktioniert, das Sie selbst geschrieben haben.

Ablauf einer HTTP-Kommunikation

Der grundsätzliche Ablauf einer HTTP-Kommunikation besteht aus zwei Teilen — Anfrage (request) und Antwort (response). Dies sieht beispielsweise folgendermaßen aus:

GET http://www.joergkrause.de/ HTTP/1.1
Accept: text/html, application/xhtml+xml, image/jxr, */*
Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; LCJB; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: www.joergkrause.de
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Sun, 17 Jan 2016 10:59:09 GMT
Server: Apache
X-Powered-By: PHP/5.5.30
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Pingback: http://www.joergkrause.de/xmlrpc.php
Link: ; rel=shortlink
Set-Cookie: PHPSESSID=4744597c154b01a61e245292b8f1a897; path=/
Keep-Alive: timeout=2, max=200
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Content-Length: 27465

Kopffelder

An ein Kommando oder an die Statuszeile können weitere Felder angehängt werden, sogenannte Kopffelder (manchmal auch Kopfzeilen genannt, weil jedes Feld auf einer Zeile steht) oder kurz Header:

Feldname: Wert; Wert

Die Nachrichtenkopffelder können in drei Hauptgruppen aufgeteilt werden:

  • F
    Frage-Felder (Request-Header-Fields), die nur in Kommandos erlaubt sind.
  • A
    Antwort-Felder (Response-Header-Fields), die Statusnachrichten vorbehalten sind.
  • I
    Informationsfelder (General-Header-Fields), dienen der Übertragung aller anderen Nachrichten in die eine oder andere Richtung.

Eine typische Anwendung, die bei der Web-Programmierung auftreten kann, ist die Übergabe eines Nachrichtenkopffeldes, der einen besonderen Dateityp für das Herunterladen einer Datei angibt:

Content-Type: application/pdf; name=aspnet.pdf

Im Gegensatz zu anderen Protokollen ist die Länge eines Datenblocks im Content-length-Kopffeld festgelegt, irgendwelche Begrenzungszeichen gibt es nicht. Wichtig ist auch, dass der Server nach dem Verbindungsaufbau keine Antwort sendet. Nur das erste eintreffende Kommando löst eine Reaktion aus. Darin ist die Ursache zu sehen, wenn der Browser nach der Anforderung eines unerreichbaren Servers lange Zeit nicht reagiert. Als „Totsignal“ wird einfach eine vorgegebene Zeitspanne gewartet, in welcher der Server auf das erste Kommando reagieren sollte.

HTTP 2.0

Die aktuelle Version von HTTP ist HTTP 2.0 (im Header als HTTP/2 bezeichnet), welche als RFC 7540 am 15. Mai 2015 veröffentlicht wurde.

Der Standard ist heute in den RFC 7540 und 7541 spezifiziert. Die Entwicklung war maßgeblich von Google (SPDY, spricht man aus wie „speedy“) und Microsoft (HTTP Speed+Mobility) mit jeweils eigenen Vorschlägen vorangetrieben worden. Ein erster Entwurf, der sich weitgehend an SPDY anlehnte, war im November 2012 publiziert und seither in mehreren Schritten angepasst worden.

Mit HTTP/2 soll die Übertragung beschleunigt und optimiert werden. Der neue Standard ist vollständig abwärtskompatibel zu HTTP/1.1.

Wichtige neue Möglichkeiten sind

  • das Zusammenfassens mehrerer Anfragen
  • bessere Kompressionsmöglichkeiten
  • binär kodierte Übertragung von Inhalten
  • Server-initiierte Datenübertragungen (push-Verfahren)

Eine Beschleunigung ergibt sich hauptsächlich aus der neuen Möglichkeit des Zusammenfassens (Multiplex) mehrerer Anfragen, um sie über eine Verbindung abwickeln zu können. Die Datenkompression kann nun auch Kopfdaten mit einschließen. Statt dem bisher benutzten Gzip oder Deflate erreicht man dies mit dem neuem Spezialalgorithmus namens HPACK.

Inhalte können binär kodiert übertragen werden. Um nicht auf serverseitig vorhersehbare Folgeanforderungen vom Client warten zu müssen, können Datenübertragungen teilweise vom Server initiiert werden (push-Verfahren).

Die ursprünglich geplante Option, dass HTTP/2 standardmäßig TLS (Transport Layer Security, früher SSL genannt, dient der Verschküsselung) nutzt, wurde nicht umgesetzt. Allerdings kündigten die Google und Mozilla für ihre Browser an, dass diese HTTP/2 nicht ohne Verschlüsselung unterstützen werden (siehe Application-Layer Protocol Negotiation). Aufgrund der Marktmacht muss man davon ausgehen, dass damit alle HTTP/2-Server zwingend TLS anbieten müssen.

Die meist verbreitetsten Browser unterstützen inzwischen HTTP/2. Darunter Google Chrome (auch unter iOS und Android) ab Version 41, Mozilla Firefox ab Version 36, Internet Explorer 11 unter Windows 10, Opera ab Version 28 (auch Opera Mobile ab Version 24) und Safari ab Version 8.

Ergänzende Standards

Flankiert wird HTTP durch weitere Standards, die entweder darauf aufsetzen oder ergänzend benutzt werden.

WebSockets

Das WebSocket-Protokoll ist ein auf TCP basierendes Netzwerkprotokoll, das entworfen wurde, um eine bidirektionale Verbindung zwischen einer Webanwendung und einem WebSocket-Server bzw. einem Webserver, der auch WebSockets unterstützt, herzustellen. Es entfallen bei WebSockets die durch den HTTP-Kopffelder verursachten zusätzlichen Daten.

Während bei einer reinen HTTP-Verbindung jede Aktion des Servers eine vorhergehende Anfrage des Clients erfordert, muss beim WebSocket-Protokoll der Client die Verbindung nur eröffnen. Der Server kann dann diese offene Verbindung aktiv verwenden und kann weitere Informationen an den Client senden, ohne auf eine neue Verbindung des Clients zu warten.

Die Anfrage wird mit einem speziellen Kopffeld aus HTTP heraus initiiert:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dJhoIeNrbgBKZrBabu5sZe==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Die Antwort sollte dann den Statuscode 101 enthalten:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: sjpoLeBrTgai9sYazGheRe+KxOo=
Sec-WebSocket-Protocol: chat

Durch den HTTP-Statuscode 101 und die folgenden zwei Zeilen erklärt der Server, dass er mit dem Wechsel des Protokolls einverstanden ist.

Technisch betrachtet startet bei WebSocket, wie bei HTTP, der Client eine Anfrage, mit dem Unterschied, dass nach der Übertragung der Daten zum Verbindungsaufbau die zugrundeliegende TCP-Verbindung bestehen bleibt und Übertragungen in beide Richtungen ermöglicht.

WebDAV

WebDAV (Web-based Distributed Authoring and Versioning) ist ein offener Standard zur Bereitstellung von Dateien im Internet. Dabei können Benutzer auf ihre Daten transparent zugreifen, also in schreibend und lesend.

Technisch gesehen ist WebDAV eine Erweiterung des Protokolls HTTP/1.1, die bestimmte Einschränkungen von HTTP aufhebt. Mit WebDAV können Dateien und auch ganze Verzeichnisse übertragen werden. Zudem ist eine Versionskontrolle spezifiziert.

Da der schreibende Zugriff auf Web-Server ziemlich riskant ist, hat WebDAV keine massive Verbreitung gefunden. Es wird, wenn überhaupt, zum Veröffentlichen von Anwendungen aus einer lokalen Entwicklungsumgebung heraus benutzt. Einige Web-Hoster und Provider bieten dies als leistungsfähige Alternative zu FTP an.

REST

REST steht für REpresentational State Transfer und bezeichnet einen Architekturstil (oder auch „Programmierparadigma für verteilte Systeme“, siehe dazu auch Wikipedia), der bereits häufig benutzte Techniken und Protokolle zusammenfasst und für die Datenübertragung nutzt. Dies umfasst:

  • URI für die Adressierung von Ressourcen
  • HTTP für Übertragung von Kommandos
  • MIME für die Kodierung der Ressourcen
  • JSON und XML für die Formatierung

Webdienst

REST ist eine spezielle Form eines Webdienstes (web service). Man spricht deshalb auch von einem REST-Dienst.

Merkmale

Die technischen Merkmale eines REST-Dienstes sind:

  • Adressierbarkeit
  • Repräsentationsvariabel
  • Zustandslosigkeit
  • Skalierbarkeit
  • Allgemeingültig
  • Erweiterbar

Adressierbarkeit

Jeder REST-konforme Dienst hat eine eindeutige Adresse, den Uniform Resource Locator (URL). Zusätzlich zum URL, der den Dienst selbst adressiert, verwendet REST auch Uniform Resource Identifier (URI), um einzelne Ressourcen zu bezeichnen.

Repräsentationsvariabel

Die unter einer Adresse zugänglichen Dienste können unterschiedliche Darstellungsformen (Repräsentationen) haben. Ein REST-konformer Server kann z.B. HTML, JSON oder XML liefern. Dies können Daten oder Beschreibungen von Daten sein.

Zustandslosigkeit

Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. Client notwendig sind, um die Nachricht zu verstehen. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (stateless) Protokoll. Jede Anfrage eines Clients beinhaltet sämtliche Informationen über den Anwendungszustand, die vom Server benötigt werden.

Skalierbarkeit

Die Zustandslosigkeit begünstigt die Skalierbarkeit eines Dienstes. Da jede Anfrage zu einer definierten Reaktion führt und keine Voraussetzungen auf einer bestimmten Maschine vorhanhden sein müssen, können Lastverteiler Anfragen auf mehrere Maschinen verteilen, ohen dass dies Änderungen an der serverseitigen Verarbeitung nach sich zieht.

Allgemeingültig

HTTP schreibt vor, dass GET „sicher“ (safe) sein muss. Dies bedeutet, dass diese Methode nur Informationen beschafft und keine Nebeneffekte hat. Die Methoden GET, HEAD, PUT und DELETE müssen idempotent sein, was bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf.

Erweiterbar

Erweiterbarkeit heißt, das später erfolgende Erweiterungen der Ressourcenbasis, zusätzliche Funktionen, mehr Daten, anderen Repräsentationen oder Skalierungsmaßnahmen sich nicht auf die bestehenden Clients auswirken dürfen.

Beispiel

Ein Merkmal von REST ist die Beschreibung von Ressourcen. Dazu gehören Links zu weiterführenden Elementen. Bestehen zwischen Daten Beziehungen, so ist dies in der Antwort zu erkennen. Eine einfach Abfrage nutzt das Kommando GET (siehe auch Abschnitt zu HTTP weiter unten).

GET /book/2605
HTTP/1.1 200 OK Content-Type: text/xml


    122
    1
    2
    JADE
    Die Template-Engine JADE
    2,99
    Paperback

Hier verweisen die URIs einiger Elemente auf abhängige Ressourcen. Der Client kann dies nutzen, um einen Teil der Benutzeroberfläche dynamisch zu erstellen.

URI

URI steht für Uniform Resource Identifier und ist das Verfahren zum Konstruieren der Adressen. Im Zusammenhang mit REST ist oft der Begriff RESTful zu sehen. Es ist wichtig zu verstehen, dass damit die korrekte Implementierung von REST gemeint ist. Das heißt nicht, das lediglich HTTP benutzt wird, sondern auch, dass die Routen, die zum Abruf von Daten und zum Auslösen von Aktionen benutzt werden, bestimmten Kriterien gehorchen.

URI wird oft mit URL (Uniform Resource Locater) verwechselt. URL ist eine Spezialform des URI. URLs dienen der Adressierung von Webseiten im Browser. URIs können dies und noch einiges andere adressieren. In URLs werden zum Anhängen von Daten Parameter benutzt, die durch ein ?Zeichen abgetrennt sind. Diesen Teil nennt man Querystring. Folgendes sind typische Anwendungsfälle:

  • /admin/updatebook.aspx?book=2605
  • /bookview.html?book=2605
  • /bookreviews.py?book=2605

Der Teil book=2605 ist der Querystring. Dies ist nicht RESTful. RESTful verlangt, dass der Datenteil als Teil der URL erfasst wird. Routen — das sind Adressierungsschemata auf Basis von URIs — haben definierte Abschnitte, denen eine Bedeutung zugewiesen wird. Diese Zuweisung ist willkürlich (Sache des Entwicklers), läuft aber häufig nach einem einfachen Prinzip:

/ressource/id

Oder etwas komplexer:

/ressource/id/aktion

RESTful würden die Beispiele eben wie folgt aussehen:

  • /admin/book/2605
  • /book/2605
  • /book/2605/view

Freilich sind hier immer noch viele Optionen vorhanden. Deshalb ein paar Regeln:

  • Kurz
    Je kürzer die URI je besser
  • Baumstruktur
    Die URI sollte die Baumstruktur des Objekt-/Datengraphen repräsentieren
  • Lesbar
    Klartext hilft
  • Voraussagbar
    Die Reaktion des Servers entspricht der Inituition beim Lesen des URI
  • Substantive
    URIs adressieren etwas, also ist das Wort eine Sache, keine Aktion. Wird eine Aktion gebraucht, hängt diese hinten an
  • QueryString I
    Ja, darf man benutzen, aber nur für genau dies: query (Abfragen/Suchen), beispielsweise:

/books/search?filter=title&value=JADE

  • QueryString II
    : Nein, wenn Parameter benötigt werden, schreibt man beispielsweise:

/books/select/quarter=2;year=2016

  • Deterministisch
    Gleiche URI ergibt immer dieselbe Ressource
  • Statuslos
    Kein Zustand auf dem Server hat Einfluss
  • Kanonisch
    Wenn zwei URIs zur selben Ressource führen, muss die Alternative in der Antwort benannt werden

Weniger wichtig, aber für guten Stil sinnvoll:

  • Nur Kleinschreibung benutzen — Camel-case und ähnliches ist hier eher störend
  • Bindestriche statt Unterstriche — book-review ist besser als book_review für Suchmaschinen
  • Plural nutzen, wenn es der Kontext erwartet (books, wenn es sich um mehrere handelt)
  • Wenn Abrufe aus Kollektionen erfolgen, sollte dies sichtbar sein: /books/book/3. Dann muss aber der Abruf /books technisch möglich sein und alle Bücher liefern. Wenn aber die Kollektion nicht geliefert werden kann, reicht /book/3.
  • Keine Leerzeichen — früher oder später sieht man nur noch %20-Fragmente (das ist ein Leerzeichen, kodiert für eine URL)

HTTP

In REST werden spezifische HTTP-Methoden benutzt, um Aktionen auf dem Server auszulösen. Konkret eingesetzt werden:

  • GET: Abrufen einer Ressource
  • POST: Ändern oder Auslösen einer Aktion
  • PUT: Erzeugen einer Ressource
  • DELETE: Löschen einer Ressource
  • PATCH: Ändern eines Teils einer Ressource
  • HEAD: Metadaten anfordern
  • OPTIONS: Erlaubte Aktionen auf einer Ressource

Es ist nicht zwingend notwendig, dies mit SQL zu vergleichen, ein einfaches Mapping kann REST aber durchaus darstellen:

{title=“Tabelle: Mapping von REST auf SQL“}

HTTP (REST) SQL
GET SELECT
POST UPDATE
PUT INSERT
DELETE DELETE

In HTTP sieht das beispielhaft folgendermaßen aus (… steht für typische Kopffelder):

POST /book/2605
...
name=Neuer Artikelname

Hierbei ist die URI ein relativer Pfad zur Ressource. basket bezeichnet die Route zu einem Controller, der sich um den Warenkorb kümmert. Die Route erwartet eine ID, die hier 2605 enthält. Damit ist im Warenkorb ein Element mit dem Primärschlüssel 2605 gemeint. Dieses Element hat eine Eigenschaft name der der neue Text „Neuer Artikelname“ zugewiesen wird.

Mittels PUT wird eine Ressource wie folgt erzeugt:

PUT /book


  JADE
  
    Die Template-Engine JADE
  
  2,99
  Paperback

Da eines der Merkmale von REST die Selbstbeschreibung ist, gibt PUT einen Link zu neuen Ressource zurück:

HTTP/1.1 201 OK
Content-Type: text/xml;
Content-Length: 34

http://shop.texxtoor.de/book/2605

Das Löschen der Ressource erfolgt ähnlich:

DELETE /book/2605

MIME

MIME steht für Multipurpose Internet Mail Extensions und wurde ursprünglich dazu entwickelt, Dokumente in E-Mails einzubetten. Dabei wird eine beschreibende Kopfzeile (header) benutzt, um das ursprüngliche Format anzuzeigen. Der Client kann dies dann wieder herstellen. Typisch ist die Zweiteilung des Formats und die Benutzung der Kopfzeile Content-Type:

gruppe/detail

Für ein Bild sieht das nun folgendermaßen aus:

Content-Type: image/jpeg

Eine genaue Beschreibung, die über das hier für REST benötigte hinausgeht, finden Sie auf Wikipedia.

Für REST wird folgendes benutzt:

  • text/xml
  • application/json

JSON

Zur Kommunikation zwischen Client und Server wird JSON eingesetzt wird. JSON (JavaScript Object Notation), gesprochen wie der Name „Jes’n“, ist ein kompaktes Format in lesbarer Textform zum Zweck des Datenaustauschs zwischen Anwendungen. Obwohl der Name auf eine alleinige Verwendung in JavaScript hindeutet, ist JSON ein unabhängiges Format, das theoretisch in jeder Programmiersprache eingesetzt werden kann.

Der am meisten betonte Unterschied von JSON zu XML ist die etwas kompaktere Kodierung von Datenstrukturen, wodurch im Gegensatz zu XML weniger Verwaltungsdaten produziert werden. Außerdem kann JSON beispielsweise in JavaScript direkt in ein JavaScript-Objekt umgesetzt werden. XML ist hingegen vielseitiger als JSON einsetzbar, das keine Auszeichnungssprache, sondern nur ein Datenaustauschformat ist. XML genießt weiterhin eine weitere Verbreitung. Beide Formate sind nicht unbedingt zum repräsentieren von großen Binärdaten geeignet.

JSON kennt Objekte, Arrays, Zeichenketten, Zahlen, Boolesche Werte und null. Daten können beliebig verschachtelt werden, beispielsweise ist ein Array von Objekten möglich. Als Zeichenkodierung benutzt JSON UTF-8.

Die JSON-Formatdefinition

Ein Objekt wird mit geschweiften Klammern umschlossen { }. Es kann eine durch Kommata geteilte, ungeordnete Liste von Eigenschaften enthalten.

Eine Eigenschaft besteht aus einem Schlüssel und einem Wert, getrennt durch einen Doppelpunkt. Der Schlüssel ist eine Zeichenkette. Der Wert ist ein Objekt, ein Array, eine Zeichenkette, eine Zahl oder einer der Ausdrücke true, false oder null. Ein Array beginnt und endet mit eckigen Klammern [ ]. Es kann eine durch Kommata geteilte, geordnete Liste von Werten enthalten. Eine Zeichenkette beginnt und endet mit Anführungszeichen („). Sie kann Unicode-Zeichen und Escape-Sequenzen enthalten. Ein Boolescher Wert wird durch die Ausdrücke true bzw. false dargestellt — ohne Anführungszeichen. Eine Zahl ist eine Folge der Ziffern 0−9. Diese Folge kann durch ein negatives Vorzeichen — eingeleitet und einen Dezimalpunkt unterbrochen sein. Die Zahl kann durch die Angabe eines Exponenten e oder E ergänzt werden, dem ein Vorzeichen „+“ oder „-“ und eine Folge der Ziffern 0-9 folgt. Leerraumzeichen sind beliebig verwendbar.

{
  "CreditCard"    : "Visa",
  "Number"        : "1234-5678-9012-3456",
  "Owner"         :
  {
    "LastName"    : "Krause",
    "Firstname"   : "Jörg",
    "Gender"        : "\"male\"",
    "Preferences" : [
      "Golf",
      "Reading",
      "Badminton"
    ],
    "Age"         : null
  },
  "Deckung"       : 10000,
  "Währung"       : "EURO"
} 

Wenn Sie mehr über JSON lesen möchten, könnten folgende Quellen interessant sein:

  • json.org bietet eine deutsche Einführung auf der offiziellen JSON-Seite.
  • Die RFC 4627 definiert mit application/json einen weiteren MIME-Typ.

Das Format ATOM

ATOM steht für Atom Syndication Format, ein plattformunabhängiges Format zum Austausch von Feeds. Es hat damit denselben Zweck wie das bekanntere RSS, das in der neuesten Version 2.0 für Really Simple Syndication steht. ATOM gilt als designierter Nachfolger von RSS 2.0. ATOM selbst ist für verschiedene Zwecke definiert, wobei hier auf ASF (ATOM Syndication Format) Bezug genommen wird. Neben der reinen Feed-Verteilung kann ATOM für Newsletter und ähnliche Zwecke eingesetzt werden. ATOM wurde in der RFC 4278 veröffentlicht. Der MIME-Typ ist application/atom+xml.



  
    Jörg Krause
  
  urn:uuid:60a76c80-9926-9905-1964-0003939e0af6
 
  
    Neues aus der Web-Welt
    
    urn:uuid:1225c695-cfb8-4ebb-aaaa-01723243189a
    2016-12-08T12:50:07Z
    Alles über Web
    Hier steht der gesamte Text
  
 

Atom in Webseiten

In Web-Anwendungen wird man ATOM nur einsetzen, wenn Clients dies explizit fordern. Der Einsatz von JSON ist deutlich einfacher und schneller.

Protokolle des Web