Leere HTTP-POST-Anforderung oder GET-Anforderung zum Generieren eines Zufallswerts über eine HTTP-API

Question

In meiner HTTP-API sollte einer der Endpunkte einen zufällig generierten Wert zurückgeben, der dem authentifizierten Aufrufer des Endpunkts zugeordnet wird. Derzeit habe ich die 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-Anfrage ausgegeben, um den Zufallswert abzurufen. Jedoch, HTTP GET calls should be idempotent und meine obige Implementierung gehorcht dieser Regel nicht. Auf der anderen Seite, Ich bin mir nicht sicher, ob es OK ist, HTTP-POST-Anfragen mit einem leeren Nachrichtentext auszustellen.

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

Answer 1

• Sicher => ob Anruf führt zu einer Änderung des Zustands auf dem Server.
• Idempotent => ob mehrere Aufrufe zu derselben Änderung auf dem Server führen.

So ist die Frage nicht die Daten, die zurückgegeben werden. Eher ist es der Server-Status: Wenn also Sie diesen Wert auf dem Server speichern, führt dies zu einer Änderung des Status, dann ist es nicht für GET geeignet. Andernfalls, wenn es die Daten sind, die zurückgegeben werden, ist es in Ordnung. Anruf an http://stackoverflow.com gibt andere Daten zurück, wenn sie 10 Minuten auseinander gerufen werden.

Schauen wir uns ein anderes Beispiel, ein Clock-Service, die die aktuelle Zeit zurückgibt. Jedes Mal, wenn Sie den Anruf tätigen, erhalten Sie einen anderen Wert, aber der Anruf selbst führt nicht zu einer Änderung des Status auf dem Server, da der Taktstatus separat verwaltet wird. Mit GET hier ist eine gute Wahl.

Answer 2

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

Darüber hinaus trägt Nachricht eine Repräsentation, die Körper + Header ist. In Ihrem Fall ist Körper 0 Länge, 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

Answer 3

Sie sollten POST in diesem Fall verwenden, da per Desgin GET Anrufe zwischengespeichert werden können. Bezüglich des leeren Postkörpers gibt es kein Problem. POST with empty body, in denen ein Beitrag erwähnt: Eine ähnliche Szenarien wird auch diskutiert

ein POST ohne Inhalt Länge und kein Körper entspricht einer POST mit Content-Length: 0 und nichts folgende, als könnte perfekt passieren, wenn Sie zum Beispiel eine leere Datei hochladen. Die Ressource wird durch die URL bestimmt und der Server muss wissen, wie er mit dem Körper umgehen soll, auch wenn er leer ist. Ich sehe das Problem nicht hier in der Tat: -/

Willy

Answer 4

Es gibt kein Problem, einen Zufallsgenerator mit einem GET, wie es kein Serverzustand ist, die gespeichert werden. Genauso könnte man einen Taschenrechner haben, der Params akzeptiert und beim Aufruf von GET hinzufügt. Die Frage nach einem Cache ist interessant, trifft aber nicht wirklich auf einen Zufallsgenerator zu, da die Ressource von Natur aus nicht zwischengespeichert wird. Das ändert nichts daran, dass es sicher/idempotent gestaltet werden kann.

Wie POST ohne einen Körper oder sogar mit Params in einer Abfragezeichenfolge, das ist in Ordnung. Das Wichtigste an POST ist, dass es möglicherweise zu einer Änderung am Server führt. Es ist auch nicht garantiert, dass es wird, aber Sie können nicht davon ausgehen, dass es nicht wie bei einem GET. Ob ein Inhalt gesetzt wird oder nicht, ändert nichts an der Tatsache, dass es eine Änderung geben kann. Stellen Sie sich zum Beispiel eine fiktive Ressource "\ counter \ increment" vor. Bei jedem POST-Vorgang wird \ counter inkrementiert. Ich habe keine Nutzlast gesendet, aber ich verursache eine Änderung im Serverstatus, daher sollte es POST oder PUT sein.