Knapp 13 Jahre ... So lange bin ich nun schon in der Web-Entwicklung mit Java. Zeit also, das Wissen einmal mit einem Zertifikat zu bestätigen. Beim durcharbeiten des Lernbuchs kamen mir dann aber doch einige grundsätzlichen Erkenntnisse. Hätte ich (wie übrigens ein Grossteil weiterer Java-Entwickler) diese Grundsätze schon früher befolgt, so wäre das Leben wohl einfacher gewesen. Konkret geht es um Grundsätze de HTTP-Protokolls. In unseren Servlets haben wir jeweils von doGet aus die Methode doPost aufgerufen (oder gar - noch schlimmer - die Methode service überschrieben), in der Annahme, dass das Verhalten möglichst gleich sein sollte. die Definition des HTTP-Protokolls sagt dazu aber etwas komplett anderes:

Das HTTP Protokoll sieht mehrere Methoden vor, welche von der Servlet-API fast durchwegs unterstützt werden. Mit der Fokussierung auf REST erhalten diese grundsätzlichen Funktionen des HTTP-Protokolls nun endlich ihre (verdiente) Aufmerksamkeit.

Ein wichtiger Punkt in Bezug auf die Http-Methoden stellt auch die Idempotenz dar. Für jede Methode ist geregelt, ob ihr mehrmaliger Aufruf Auswirkungen auf die Datenkonstellation haben darf oder nicht, d.h. ob durch den Aufruf der Methode der Zustand auf dem Server geändert wird.

Die Klasse Servlet stellt die Methode service(req, resp) zur Verfügung, welche abhängig von der HTTP-Methode die entsprechende Servlet-Methode aufruft. Soll ein Servlet unabhängig von der HTTP-Methode immer gleich reagieren, so kann die Methode service überschrieben werden. Dies wird aber nicht empfohlen.

GET (doGet) *
Die Methode get wird genutzt, um Inhalt vom Server abzufragen. Ein get ist immer idempotent.

POST (doPost) *
Die Methode post wird genutzt, um Inhalte auf den Server zu übermitteln. Es wird dem Server überlassen, was mit dem Inhalt geschieht (Ersetzen des bishierigen, Ergänzen zum bisherigen, Update, ...). Der post ist NICHT idempotent.

DELETE (doDelete) **
Die Methode delete wird genutzt um Inhalte vom Server zu löschen. Delete ist nicht idempotent.

PUT (doPut) **
Ist vergleichbar mit post, ersetzt aber in jedem Fall den Inhalt der angegenbenen URL durch den neuen (delete/insert oder nur insert). Der put ist daher immer idempotent.

HEAD (doHead) **
Die Methde head enspricht in etwa dem get., liefert aber nur den HTTP Header zurück, und nicht den Body. Sinn dahinter ist, den Netzwerkverkehr zu minimieren. Ein Client kann mit dem vorgängigen Abfagen des Headers prüfen, ob der get überhaupt ausgeführt werden soll, oder ob er die entsprechenden Daten in seinem Cache bereits verfügbar hat.

OPTIONS (doOptions) **
Dient dazu, die unterstützten http-Methoden zu prüfen.

TRACE (doTrace) **
Trace könnte mit einem ping verglichen werden. Die Antwort sollte vom Content-Typ message/http sein.

CONNECT (n.A.) **
Ist reserviert für Proxies.

So kommt es nun, dass ich nach 13 Jahren grundsätzliches neu lerne mit der Erkenntnis, dass entsprechende Ausbildungen zu einem früheren Zeitpunkt effektiver wären und gerade in der Softwareentwicklung zu besseren und stabileren Anwendungen führen würden.

* Prüfungsstoff
** kein Prüfungsstoff