Lobster Experten Fragen

HTTP

Das Hypertext Transfer Protocol HTTP kennt jeder – ohne gäbe es kein Internet, wie wir es heute kennen. Es diente ursprünglich zum Transport von HTML-Seiten und Bildern, ist jedoch inzwischen stark erweitert worden und bietet für sich alleine schon diverse Möglichkeiten, beliebige Daten zu transferieren. HTML-Formulare, auch mit der Funktion des Datei-Uploads, sind lange Standard im Netz, und zum Download werden praktisch alle Arten von Dateien angeboten. Funktionsweise und Geschichte können bei Wikipedia nachgelesen werden.
Basierend auf dem reinen HTTP-Protokoll sind inzwischen auch weitere Protokolle geschaffen worden, die auf diverse Aspekte der Datenübertragung zugeschnitten sind. Hier sind vor allem WebDAV und AS2 zu nennen. Zu diesen beiden gibt es eigene Artikel. Wir wollen den Einsatz des ursprünglichen HTTP-Protokolls im EDI-Umfeld beleuchten.

Im Browser oder automatisch

Die gerade angesprochenen HTML-Formulare sind, zusammen mit den Download-Links auf Webseiten, die den meisten Benutzern vertraute Art, Daten per HTTP zu übertragen. Man kann ein paar Informationen eingeben, eventuell noch eine Datei zum Upload mit angeben (oder sogar mehrere), und mit einem Druck auf’s Knöpfchen geht alles zum Webserver. Der kann dann womöglich, nach Auswertung der Angaben, nicht nur mit einer Webseite antworten, sondern mit einer ganzen Datendatei, die man auf der Plate speichern kann. Zum Klick auf einen Download-Link müssen wir wohl nichts sagen. Beispielsweise können Sie sich bei einem internationalen Paketdienst (mit braunen Autos) anmelden und bekommen dann speziell für Sie erstellte Seiten zu sehen, die z.B. Rechnungen ihrer Firma per Download zur Verfügung stellen.
Das wäre aber noch kein wirkliches EDI, denn nur auf einer Seite steht ein System, das Daten selbständig entgegennimmt und verarbeitet bzw. auch bereitstellt. Auf der anderen Seite sitzt ein Mensch vor dem Browser. Nur … das muss ja nicht so sein. Alles, was ein Mensch in einem Formular angeben kann (und erst recht, was in einem simplen Link steht), kann auch eine Software automatisch eintragen.

Einfache GET Requests

Wenn Sie in der Lage sind, mit einem Klick auf diesen Link eine Datei zu laden (was ja letztlich auch nur Ihr Browser für Sie übernimmt), kann auch ein EDI-System sich Daten besorgen, indem es dieselbe URL anspricht: http://lobster.de/wp-content/uploads/2014/06/Lobster_data_Broschüre_web_2014.pdf
Zugegeben, das ist ein schlechtes Beispiel für EDI, da ein PDF-Dokument ja nun gerade nicht für EDI-Prozesse geeignet ist.

Die oben dargestellte URL enthält tatsächlich nur die Adresse eines Dokumentes. Wollen Sie Daten versenden, können diese einfach mit in die URL gesetzt werden:
http://www.example.com/formular.cgi?parameter1=wert1&parameter2=wert2
(näheres dazu bei Wikipedia)

Diese Methode, Daten an den Server zu senden, nennt sich GET. Sie birgt einige Nachteile. Zum einen kann man in die URL nur eine begrenzte Anzahl relativ kleiner Werte stecken. Einige ganz alte Webserver vertragen URLs nur bis zu 255 Zeichen Länge, und irgendwann wird’s ja auch unübersichtlich. Dateien sind damit praktisch nicht übertragbar. Und mitlesen kann das auch noch jeder, da die ganze URL offen über’s Netz geht und sogar auf diversen Rechnern zu Caching-Zwecken zwischengespeichert werden kann.
Aber zusammen mit Authentifizierungsmechanismen wie HTTP Basic Authentication kann es durchaus dazu taugen, zu einer bestimmten Kundennummer und einem vorgegebenen Datum z.B. alle neuen Aufträge abzuholen.

Komplexer: POST

Hier muss man eigentlich drei Varianten unterscheiden:

  • Einfaches POST: Was bei GET in der URL stünde, wird nun als Body des Requests über einen Datenstrom an den Server geschickt. Also z.B.: parameter1=wert1&parameter2=wert2&Datei=Langer%20Text.
  • Raw POST: eignet sich wunderbar, um eine einzelne Datei direkt zum Server zu senden. Der Body, also der Datenstrom, der nach den Headern zum Server geht, enthält den Dateiinhalt, so, wie er ist. Man muss hier auch keine spezielle Zeichen extra codieren, wie im Beispiel zum einfachen POST das Leerzeichen durch %20 (was bei einem GET übrigens erst recht nötig wäre).
  • Multipart/Form-Data: Man könnte es als eine Kombination aus den anderen beiden anderen sehen. Einerseits kann man damit wie mit einem Raw POST sehr gut große Dateien übertragen (meist Base64-codiert), andererseits kann man aber mehrere Parameter (und sogar mehrere Dateien) kombinieren. Der Body wird, ähnlich wie bei einer E-Mail mit mehreren Anhängen, in einzelne Teile untergliedert, von denen jeder einen Parameter enthält. Ob dieser Parameter nur einen kurzen Text oder eine ganze binäre Datei enthält, ist dabei egal. Durch Nutzung von MIME-Typen und entsprechenden Content Encodings kann jeder Teil passend zu seinem Inhalt übertragen werden.

Jede Variante hat so ihre Vor- und Nachteile. Sie sollten im Einzelfall entscheiden können, welche Sie einsetzen. HTML-Formulare verwenden meist entweder einfaches POST, wenn nur ein paar Angaben zu übertragen sind, oder gleich Multipart/Form-Data, wenn auch Dateien mitgesendet werden sollen. Daher auch der Name „Multipart/Form-Data„. Das Kontaktformular dieser Seiten beginnt übrigens auch mit folgendem HTML-Tag:

<form enctype="multipart/form-data" method="post" ...>

Identifizierung

Ursprünglich diente HTTP dazu, Informationen möglichst der ganzen Welt zur Verfügung zu stellen. Doch sehr schnell gab es die ersten Inhalte, die eben doch nur einem begrenzten Nutzerkreis zugänglich sein sollten. Also gibt es auch Möglichkeiten, den Nutzer oder das System, kurz: den Client, der eine URL aufruft, zu identifizieren. Umgekehrt möchte manchmal auch der Client sicher sein, den richtigen Server anzusprechen und nicht irgendwelchen Phishern oder Spoofern aufzusitzen.

  • Eine einfache Art, den Client gegenüber dem Server zu identifizieren, sind Nutzername und Passwort. Die Übertragung dieser Angaben kann prinzipiell auf zwei verschiedene Arten erfolgen, die hier näher beschrieben sind (Nun gut, da sind drei Arten genannt, aber eine davon ist kein Standard).
  • Der Server umgekehrt kann sich eigentlich nur dem Client gegenüber identifizieren, indem er ein beglaubigtes Zertifikat vorlegt. Das passiert in dem Moment, wo HTTPS ins Spiel kommt, also die SSL-Verschlüsselung der HTTP-Übertragungen. Sie werden sicher schon auf den einen oder anderen Dialog gestoßen sein, der Ihnen meldete, dass das Zertifikat eines Servers aus diesen oder jenen Gründen nicht vertrauenswürdig sei. Bei vielen Seiten ignoriert man die Warnung, bei seiner Bank dann aber hoffentlich nicht mehr.
  • Denselben Mechanismus kann man auch nutzen, um den Client als tatsächlich berechtigten User auszuweisen. Dazu wird das mit dem Zertifikat einfach umgedreht. Der Client übergibt seinerseits dem Server ein Zertifikat, das dieser überprüfen kann. In Szenarien, die nur einen genau definierten Kreis von Clients zulassen, kann z.B. das gültige Zertifikat einfach beim Server hinterlegt sein.

Vorsicht, Lauscher!

HTTP selbst besitzt keine Verschlüsselung. Selbst HTTP Basic Authentification, die einfachste Art, sich an einem Webserver „einzuloggen“, überträgt Username und Passwort zwar Base64-codiert, aber nicht verschlüsselt. Wenn man also einigermaßen sicher gehen will, dass niemand mithört, sollte man eine HTTPS-Verbindung nutzen, die alles, was über die Leitung geht, SSL-verschlüsselt.

WebServices

WebServices und HTTP hängen nicht zwingend miteinander zusammen, allerdings werden in der Praxis die allermeisten WebServices via HTTP angesprochen, da sich dieses Protokoll als Frage-Antwort-Protokoll wunderbar eignet. Man sendet eine Anfrage an den Server und bekommt sofort als Antwort das Ergebnis der Anfrage. Theoretisch ließen sich WebServices aber auch via FTP oder gar E-Mail abwickeln, wenn Antwortzeiten keine große Rolle spielen.
Die meistgenutzte Sorte von WebServices sind SOAP-Requests, allerdings gibt es auch andere „Geschmacksrichtungen“, wie z.B. REST oder RPC. Ausführlich ist das alles wieder mal bei Wikipedia beschrieben. Um wenigstens SOAP kurz anzureißen, das funktioniert so:
Der Client (z.B. eine EDI-Software) schickt ein XML-Dokument mit einer Anfrage (HTTP POST) an den Server. Diese Anfrage kann eine Bestandabfrage sein, eine Zimmerreservierung oder was auch immer der Server anzunehmen bereit ist. Das XML-Dokument besteht aus einem sogenannten SOAP Envelope mit ein paar Header-Daten und einem SOAP Body mit den eigentlichen Nutzdaten der Anfrage.
Der Server (auch das kann ein EDI-System sein) nimmt das XML entgegen, wertet es aus, steckt das Ergebnis wiederum in einen SOAP Body, der in einen SOAP Envelope kommt, und reicht diesen als Antwort auf den Request an den Client zurück.
In dem Artikel über EAI und EDI sind kleine Beispiele solcher SOAP-XML-Anfragen zu finden.

Vorteile

  • Das schöne an HTTP ist, dass es ein Frage-Antwort-Protokoll ist. Während man eine E-Mail einfach abfeuert und hofft, dass sie ankommt, und FTP lediglich eine erfolgreiche Übertragung der Daten bestätigen kann, hat HTTP das Zeug, auch gleich Auskunft darüber zu geben, ob die Daten auch verarbeitet werden konnten. Ja, es kann sogar – wie ein WebService – das Ergebnis dieser Verarbeitung zurücksenden. Und das, wohlgemerkt, synchron, also direkt als Antwort auf den eingehenden Request.
  • Wenn es irgend etwas gibt, das durch die meisten Firewalls dieser Welt durchkommt, dann ist es das HTTP-Protokoll.
  • HTTP-Server gibt es wie Sand am Meer, die bekanntesten sind sicher Apache und MS IIS.
  • Eine HTTP-basierte Schnittstelle zum Datei-Up/Download kann, wenn sie entsprechend designed ist, gleichermaßen vom Menschen am Browser wie auch von einer automatisch arbeitenden Software angesprochen werden.

Nachteile

  • HTTP wurde ursprünglich nicht für den Austausch wichtiger Geschäftsdaten konzipiert. Zwar gibt es Mechanismen zur Authentifizierung sowohl des Clients gegenüber dem Server als auch anders herum, und die Daten können auch verschlüsselt werden. Jeder dieser Mechanismen für sich ist standardisiert, aber nicht ihre Kombination. Im Prinzip kann sich jeder die Techniken herauspicken, die er persönlich für sinnvoll hält.
  • Die Signatur von Daten ist im HTTP-Protokoll und seinen „Anhängseln“ nicht möglich. Es kann also letztlich nicht nachgewiesen werden, dass bestimmte Daten auch wirklich unverfälscht von dem kommen, der sie vermeintlich abgesendet hat.

Diese Nachteile werden durch den Standard AS2 adressiert. AS2 nutzt als Übertragungsprotokoll HTTP, jedoch sind hier diverse Mechanismen festgelegt, wie die Authentifizierung zwischen den beteiligten Kommunikationspartnern zu geschehen hat, wie die Daten verschlüsselt und signiert werden usw. AS2 kann auch nur zwischen zwei Partnern gesprochen werden, die sich vorher darauf verständigt und untereinander Kennungen und Zertifikate ausgetauscht haben. Und: Für AS2-Software gibt es eine Art Gütesiegel, das garantiert, dass sich diese Software an den definierten Standard hält. Alles weitere dazu in einem eigenen Artikel.
Wenn Sie Benutzern die Möglichkeit bieten wollen, sowohl manuell als auch automatisiert Daten zu oder von Ihnen zu übertragen, ist HTTP eine feine Sache. Sinnvollerweise sollte die EDI-Software auch HTTP-Schnittstellen zur Verfügung stellen bzw. sich an einen der verbreiteten Webserver anbinden lassen. Haben Sie hohe Anforderungen bzgl. der Sicherheit, sollten Sie allerdings auf ein EDI-System mit AS2-Integration setzen.