HTTP POST mit URL-Abfrageparametern - gute Idee oder nicht?

Question

Ich entwerfe eine API, die über HTTP läuft, und ich frage mich, ob die Verwendung des HTTP POST-Befehls, aber nur mit URL-Abfrageparametern und ohne Anfragebody, ein guter Weg ist, um zu gehen.

Erwägungen:

• "Gutes Webdesign" verlangt, dass nicht-idempotente Aktionen per POST gesendet werden. Dies ist eine nicht-idempotente Aktion.
• Es ist einfacher, diese Anwendung zu entwickeln und zu debuggen, wenn die Anfrageparameter in der URL enthalten sind.
• Die API ist nicht für eine breite Anwendung gedacht.
• Es scheint, dass eine POST-Anfrage ohne Body etwas mehr Arbeit erfordert, z.B. eine Content-Length: 0 Kopfzeile muss explizit hinzugefügt werden.
• Es scheint mir auch, dass ein POST ohne Body den Erwartungen der meisten Entwickler und HTTP-Frameworks widerspricht.

Gibt es weitere Fallstricke oder Vorteile bei der Übermittlung von Parametern bei einer POST-Anforderung über die URL-Abfrage und nicht über den Anforderungskörper?

Bearbeiten: Der Grund, warum dies in Erwägung gezogen wird, ist, dass die Operationen nicht idempotent sind und andere Nebeneffekte als das Abrufen haben. Siehe die HTTP-Spezifikation :

Insbesondere wurde die Konvention festgelegt, dass die Methoden GET und HEAD Methoden NICHT die Bedeutung haben sollen Bedeutung haben, eine andere Aktion als das Abrufen. Diese Methoden sollten als "sicher" angesehen werden. Dies erlaubt den Benutzer Agenten, andere Methoden darzustellen, wie POST, PUT und DELETE, in einer speziellen Art und Weise darzustellen, so dass dem Benutzer die darauf aufmerksam gemacht wird, dass eine möglicherweise unsichere Aktion angefordert wird.

...

Methoden können auch die Eigenschaft haben "Idempotenz" haben, indem sie (abgesehen von Fehler- oder Verfallsproblemen) die Nebeneffekte von N > 0 identischen Anfragen die gleichen sind wie bei einer einzigen Anfrage. Die Methoden GET, HEAD, PUT und DELETE haben diese Eigenschaft gemeinsam. Außerdem die Methoden OPTIONS und TRACE SHOULD KEINE Seiteneffekte haben und sind daher von Natur aus idempotent.

Answer 1

Die Verwendung von Abfrageparametern an einem POST-Endpunkt wäre in Ordnung, sofern sie sich auf eine bereits vorhandene Ressource beziehen.

Zum Beispiel:

POST /user_settings?user_id=4
{
  "use_safe_mode": 1
}

Der obige POST enthält einen Abfrageparameter, der auf eine vorhandene Ressource verweist. Der Parameter body definiert die neu zu erstellende Ressource.

Bearbeitet:

Ich ziehe es vor, dass der Pfad des Endpunkts direkt auf den bereits bestehenden Rückgriff verweist, etwa so:

POST /user_settings/4
{
...
}

Der Grund dafür ist dreifach:

1. Ich finde, dass es besser lesbar ist, da die Abfrageparameter benannt werden, wie z. B. "user_id" in dem obigen Beispiel, anstatt nur "4".
2. Normalerweise gibt es auch einen GET-Endpunkt, um die Ressource abzurufen. In diesem Fall sind der Pfad des Endpunkts und die Abfrageparameter identisch, und ich mag diese Symmetrie.

3. Ich finde, dass die Verschachtelung umständlich und schwer lesbar werden kann, wenn mehrere Parameter benötigt werden, um die bereits vorhandene Ressource zu definieren:

   POST /user_settings/{user_id}/{which_settings_id}/{xyz}/{abc}/ ... { ... }