Zum Hauptinhalt springen

5. Request/Response Semantics (Anfrage/Antwort-Semantik)

CoAP arbeitet unter einem Anfrage/Antwort-Modell ähnlich wie HTTP: Ein CoAP-Endpunkt in der "Client"-Rolle sendet eine oder mehrere CoAP-Anfragen an einen "Server", der die Anfragen durch Senden von CoAP-Antworten bearbeitet. Im Gegensatz zu HTTP werden Anfragen und Antworten nicht über eine zuvor hergestellte Verbindung gesendet, sondern asynchron über CoAP-Datagramme ausgetauscht.

5.1. Requests (Anfragen)​

Eine CoAP-Anfrage besteht aus der Methode, die auf die Ressource angewendet werden soll, dem Identifikator der Ressource, einer Nutzlast und einem Internet-Medientyp (falls vorhanden) sowie optionalen Metadaten über die Anfrage.

CoAP unterstützt die grundlegenden Anfragemethoden GET, POST, PUT und DELETE, die leicht auf HTTP abgebildet werden können. Sie haben auch die Eigenschaften sicher (Safe) und idempotent (Idempotent), wie sie in HTTP definiert sind.

5.1.1. Method Definitions (Methodendefinitionen)​

In diesem Abschnitt definieren wir die CoAP-Methoden.

  • GET: Die GET-Methode ruft eine Darstellung der Informationen ab, die derzeit der durch den Anfrage-URI identifizierten Ressource entsprechen.
  • POST: Die POST-Methode fordert an, dass die in der Anfrage enthaltene Darstellung von der durch den Anfrage-URI identifizierten Ressource verarbeitet wird.
  • PUT: Die PUT-Methode fordert an, dass die durch den Anfrage-URI identifizierte Ressource mit der in der Anfrage enthaltenen Darstellung aktualisiert oder erstellt wird.
  • DELETE: Die DELETE-Methode fordert an, dass die durch den Anfrage-URI identifizierte Ressource gelöscht wird.

5.2. Responses (Antworten)​

Nach Empfang und Interpretation einer Anfrage antwortet ein Server mit einer CoAP-Antwort, die mit der Anfrage durch ein vom Client generiertes Token abgeglichen wird.

Eine Antwort wird durch einen Antwortcode (Response Code) identifiziert, der analog zum HTTP-Statuscode ist. Die Antwortcodes zeigen das Ergebnis des Versuchs an, die Anfrage zu verstehen und zu erfüllen.

5.2.1. Response Code Definitions (Definitionen der Antwortcodes)​

Die Antwortcodes sind in Klassen gruppiert:

  • 2.xx (Erfolg): Die Anfrage wurde erfolgreich empfangen, verstanden und akzeptiert.
  • 4.xx (Client-Fehler): Die Anfrage enthält eine fehlerhafte Syntax oder kann nicht erfüllt werden.
  • 5.xx (Server-Fehler): Der Server konnte eine scheinbar gültige Anfrage nicht erfüllen.

5.3. Request/Response Matching (Anfrage/Antwort-Abgleich)​

Unabhängig davon, wie eine Antwort gesendet wird (z. B. in einer Bestätigungsnachricht oder einer separaten bestätigbaren Nachricht), wird sie mit der Anfrage durch das vom Client in der Anfrage enthaltene Token abgeglichen. Das Token muss für das gegebene Quell-/Zielpaar während der Lebensdauer des Austauschs eindeutig sein.

5.4. Options (Optionen)​

CoAP definiert eine Reihe von Optionen, die in eine Anfrage oder Antwort aufgenommen werden können. Optionen bieten zusätzliche Metadaten, wie das Inhaltsformat, den Zielhost oder Entity-Tags (ETags) zur Cache-Validierung.

5.5. Payload (Nutzlast)​

CoAP-Anfragen und -Antworten können eine Nutzlast enthalten. Die Nutzlast ist die Darstellung der Ressource (für eine GET-Antwort oder eine PUT-Anfrage) oder die zu verarbeitenden Daten (für eine POST-Anfrage). Das Format der Nutzlast wird durch die Option Content-Format angegeben.

5.6. Caching (Caching)​

CoAP unterstützt das Caching von Antworten, um den Netzwerkverkehr und die Latenz zu reduzieren. Das Caching-Modell ähnelt dem von HTTP und verwendet Frische-Indikatoren (Max-Age) und Validierungs-Indikatoren (ETag).

5.7. Proxying (Proxying)​

CoAP ist so konzipiert, dass ein effizientes Proxying möglich ist. Proxys können verwendet werden, um Antworten zwischenzuspeichern, eine Protokollübersetzung durchzuführen (z. B. CoAP zu HTTP) oder Nachrichten an andere Netzwerke weiterzuleiten.

5.8. Method Definitions (Methodendefinitionen) - Details​

  • GET: Sicher und idempotent.
  • POST: Weder sicher noch idempotent.
  • PUT: Idempotent, aber nicht sicher.
  • DELETE: Idempotent, aber nicht sicher.

5.9. Response Code Definitions (Definitionen der Antwortcodes) - Details​

  • Created (2.01): Wie HTTP 201 Created.
  • Deleted (2.02): Wie HTTP 204 No Content (aber spezifisch für DELETE).
  • Valid (2.03): Wie HTTP 304 Not Modified.
  • Changed (2.04): Wie HTTP 204 No Content (aber spezifisch für POST/PUT).
  • Content (2.05): Wie HTTP 200 OK.
  • Bad Request (4.00): Wie HTTP 400 Bad Request.
  • Unauthorized (4.01): Wie HTTP 401 Unauthorized.
  • Bad Option (4.02): Eine der Optionen in der Anfrage wird nicht unterstützt.
  • Forbidden (4.03): Wie HTTP 403 Forbidden.
  • Not Found (4.04): Wie HTTP 404 Not Found.
  • Method Not Allowed (4.05): Wie HTTP 405 Method Not Allowed.
  • Not Acceptable (4.06): Wie HTTP 406 Not Acceptable.
  • Precondition Failed (4.12): Wie HTTP 412 Precondition Failed.
  • Request Entity Too Large (4.13): Wie HTTP 413 Request Entity Too Large.
  • Unsupported Content-Format (4.15): Wie HTTP 415 Unsupported Media Type.
  • Internal Server Error (5.00): Wie HTTP 500 Internal Server Error.
  • Not Implemented (5.01): Wie HTTP 501 Not Implemented.
  • Bad Gateway (5.02): Wie HTTP 502 Bad Gateway.
  • Service Unavailable (5.03): Wie HTTP 503 Service Unavailable.
  • Gateway Timeout (5.04): Wie HTTP 504 Gateway Timeout.
  • Proxying Not Supported (5.05): Der Server ist ein Proxy, unterstützt aber den angeforderten Proxy-URI nicht.
Letztes Update am