3.1. Generische Semantik

3.1. Generische Semantik

Ein Großteil des Wertes von HTTP liegt in seiner generischen Semantik -- das heißt, die von HTTP definierten Protokollelemente sind potenziell auf jede Ressource anwendbar und sind nicht spezifisch für einen bestimmten Kontext. Anwendungsspezifische Semantik wird am besten in Nachrichteninhalten und Header-Feldern ausgedrückt, nicht in Statuscodes oder Methoden (obwohl Statuscodes und Methoden generische Semantik haben, die sich auf den Anwendungsstatus bezieht).

Diese Trennung zwischen generischer und anwendungsspezifischer Semantik ermöglicht es, eine HTTP-Nachricht durch gemeinsame Software (z. B. HTTP-Server, Zwischenstellen, Client-Implementierungen und Caches) zu behandeln, ohne dass diese Implementierungen die verwendete Anwendung verstehen müssen. Sie ermöglicht es Menschen auch, ihr Wissen über HTTP-Semantik zu nutzen, ohne spezialisiertes Wissen über eine bestimmte Anwendung zu benötigen.

Daher DÜRFEN Anwendungen, die HTTP verwenden, die Semantik generischer Protokollelemente wie Methoden, Statuscodes oder bestehende Header-Felder NICHT neu definieren, verfeinern oder überlagern. Stattdessen sollten sie ihre Spezifikationen auf Protokollelemente konzentrieren, die spezifisch für ihre Anwendung sind -- nämlich ihre HTTP-Ressourcen.

Siehe [BCP190] für weitere Informationen.

Beim Schreiben einer Spezifikation ist es oft verlockend, genau festzulegen, wie HTTP implementiert, unterstützt und verwendet werden soll. Dies kann jedoch leicht zu einem unbeabsichtigten Profil des HTTP-Verhaltens führen. Beispielsweise ist es üblich, Spezifikationen mit einer Sprache wie dieser zu sehen:

Eine POST-Anfrage MUSS zu einer 201 Created-Antwort führen.

Dies bildet eine Erwartung beim Client, dass die Antwort immer 201 Created sein wird, obwohl diese Antwort tatsächlich überhaupt nicht sicher ist. Sie wird nur erwartet, wenn der Server glaubt, dass eine neue Ressource erstellt wurde, aber verschiedene Gründe (wie Sicherheitsrichtlinien) könnten den Server daran hindern, eine neue Ressource zu erstellen oder zu bestätigen, dass die Ressource erstellt wurde.

Angemessenere Sprache wäre:

Eine erfolgreiche POST-Anfrage SOLLTE zu einer 201 Created-Antwort führen, wenn eine Ressource erstellt wurde.

Eine Spezifikation kann spezifische Instanzen von Protokollelementen verwenden, um anwendungsspezifische Semantik zu signalisieren. In gewissem Sinne ist dies, wie die generische Semantik für die Anwendung spezialisiert wird. Beispielsweise könnte eine Anwendung eine POST-Anfrage mit einem bestimmten Content-Type definieren, um "eine neue Ressource mit der beigefügten Darstellung erstellen" zu bedeuten. Da die Semantik anwendungsspezifisch ist, muss sie in der Spezifikation der Anwendung definiert werden.

Siehe Abschnitt 4.7 für Details zu anwendungsdefinierten Header-Feldern.