wake-up-neo.com

Leeres HTTP POST Anfrage oder GET-Anfrage zum Generieren eines Zufallswerts über eine HTTP-API

In meiner HTTP-API sollte einer der Endpunkte einen zufällig generierten Wert zurückgeben, und dieser Wert wird dem authentifizierten Aufrufer des Endpunkts zugeordnet. Derzeit habe ich folgende Struktur:

GET http://example.com/random-ticket HTTP/1.1
Authorization: Basic base64-encoded-basic-auth-value
Accept: application/json
Host: example.com

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: application/json; charset=utf-8
Date: Thu, 03 Oct 2013 07:25:56 GMT
Content-Length: 59

{"user-ticket":"Pfa42634e-1a2e-4a7d-84b9-2d5c46a8dd81"}

Eine GET-Anforderung wird ausgegeben, um den Zufallswert abzurufen. HTTP-GET-Aufrufe sollten jedoch idempotent sein und meine obige Implementierung beachtet diese Regel nicht. Andererseits Ich bin nicht sicher, ob es in Ordnung ist, HTTP POST -Anforderungen mit einem leeren Nachrichtentext abzusetzen.

Was ist der richtige Weg, um diese Art von Operationen mit dem HTTP-Buch durchzuführen?

13
tugberk
  • Sicher => ob der Aufruf zu einer Statusänderung auf dem Server führt.
  • Idempotent => ob mehrere Anrufe auf dem Server zur gleichen Änderung führen.

Die Frage sind also nicht die Daten, die zurückgegeben werden. Es ist vielmehr der Serverstatus: also wenn sie speichern diesen Wert auf dem Server Dies führt zu einer Änderung des Status, dann ist es nicht für GET geeignet. Andernfalls sind die zurückgegebenen Daten in Ordnung. Rufen Sie http://stackoverflow.com auf und geben Sie andere Daten zurück, wenn Sie im Abstand von 10 Minuten aufgerufen werden.

Schauen wir uns ein anderes Beispiel an, einen Uhrendienst , der die aktuelle Zeit zurückgibt. Bei jedem Aufruf wird ein anderer Wert angezeigt, der Aufruf selbst führt jedoch nicht zu einer Statusänderung auf dem Server, da der Uhrzeitstatus separat verwaltet wird. Daher ist die Verwendung von GET hier eine gute Wahl.

15
Aliostad

Es gibt absolut nichts im HTTP, was die Verwendung von POST mit einem leeren Körper verbietet.

Darüber hinaus enthält die Nachricht eine Darstellung, bei der es sich um body + headers handelt. In Ihrem Fall hat body die Länge 0, was in Ordnung ist, und die Header, die den Benutzer identifizieren.

Siehe Diskussion hier - http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0273.html

11
Filip W

Es ist kein Problem, einen Zufallsgenerator mit einem GET zu haben, da kein Serverstatus gespeichert wird. Auf die gleiche Weise könnten Sie einen Taschenrechner haben, der Parameter akzeptiert und sie hinzufügt, wenn ein GET aufgerufen wird. Die Frage zu cachable ist interessant, gilt jedoch nicht für einen Zufallsgenerator, da die Ressource von Natur aus nicht zwischengespeichert ist. Das ändert aber nichts an der Tatsache, dass es sicher/idempotent gestaltet werden kann.

Bezüglich POST ohne einen Textkörper oder sogar unter Verwendung von Parametern in einer Abfragezeichenfolge ist das in Ordnung. Das Wichtigste an POST ist, dass dies zu einer Änderung des Servers führen kann. Es ist auch nicht garantiert, dass dies der Fall ist, aber Sie können nicht davon ausgehen, dass dies nicht der Fall ist, wie bei einem GET. Unabhängig davon, ob Inhalte festgelegt wurden oder nicht, ändert dies nichts an der Tatsache, dass Änderungen möglich sind. Stellen Sie sich zum Beispiel eine fiktive Ressource "\ counter\increment" vor. Jedes Mal, wenn Sie POST eingeben, wird\counter inkrementiert. Ich habe keine Nutzdaten gesendet, aber ich verursache eine Änderung im Serverstatus, daher sollte es POST oder PUT sein.

4
Glenn Block

In diesem Fall sollten Sie POST verwenden, da GET-Aufrufe nach Wunsch zwischengespeichert werden können. Bezüglich des leeren Pfostenkörpers gibt es kein Problem. Ein ähnliches Szenario wird auch unter: POST mit leerem Text behandelt, wobei in einem Beitrag Folgendes erwähnt wird:

ein POST ohne inhaltliche Länge und ohne Textkörper entspricht einem POST mit inhaltlicher Länge: 0 und nichts Folgendem, wie es beispielsweise beim Hochladen einer leeren Datei durchaus vorkommen könnte. Die Ressource wird durch die URL bestimmt und der Server muss wissen, wie er mit dem Body umgeht, auch wenn er leer ist. Ich sehe das Problem hier nicht in der Tat: - /

Willy

1
Aziz Shaikh