Die Inhaltsverhandlung ermöglicht es, dass eine URL verschiedene Darstellungen bereitstellt. Der Client gibt an, welche Inhalte er akzeptiert; der Server wählt die gewünschte Darstellung aus; die Antwort gibt an, welche ausgewählt wurde. Die Ressource selbst bleibt dabei gleich – nur die Darstellung unterscheidet sich.
Der Client sendet eine Accept-Anfrage mit den gewünschten Medientypen, optional mit q-Werten. Der Server antwortet mit einem Content-Type, der den tatsächlich gesendeten Inhalt angibt, und sollte Vary: Accept senden, damit Caches keine JSON-Antwort an einen Client ausliefern, der CSV angefordert hat. Kann der Client keine akzeptierten Daten liefern, lautet die Antwort 406 Not Acceptable. Im umgekehrten Fall – wenn der Client einen Body in einem vom Server nicht unterstützten Format sendet – lautet die Antwort 415 Unsupported Media Type.
Der Accept-Header ist lediglich eine Empfehlung und kann ignoriert werden. Viele APIs ignorieren ihn und geben immer JSON zurück. Das funktioniert, bis ein Client tatsächlich etwas anderes benötigt und stillschweigend JSON mit dem Statuscode 200 erhält. Die korrekte Antwort auf einen nicht erfüllbaren Accept-Header ist ein 406-Fehler.
Das Protocol Lab verhandelt tatsächlich: `GET /protocol/v1/export/documents` liefert je nach Accept-Header JSON, CSV oder XML, setzt den Content-Type entsprechend und antwortet mit 406, anstatt stillschweigend eine andere Antwort zu senden, wenn die Anfrage nicht erfüllt werden kann. Die Friends API hingegen sendet beim Aufruf einen 415-Fehler.
Diese Seite auf Englisch lesen
Alle Glossarbegriffe · Testtechniken · Alle 39 Mock-REST-APIs
Zuletzt aktualisiert