PUT vs. POST in REST

Insgesamt:

Sowohl PUT als auch POST können zur Erstellung verwendet werden.

Um zu unterscheiden, was Sie verwenden sollten, müssen Sie sich fragen: "Wofür führen Sie die Aktion aus?". Nehmen wir an, Sie entwickeln eine API, um Fragen zu stellen. Wenn Sie POST verwenden möchten, dann würden Sie dies mit einer Liste von Fragen tun. Wenn Sie PUT verwenden möchten, dann würden Sie dies für eine bestimmte Frage tun.

Großartig, beide können verwendet werden, also welche sollte ich in meinem RESTful-Design verwenden:

Sie müssen nicht sowohl PUT als auch POST unterstützen.

Welches verwendet wird, bleibt Ihnen überlassen. Denken Sie aber daran, die richtige zu verwenden, je nachdem, auf welches Objekt Sie in der Anfrage verweisen.

Einige Überlegungen:

• Benennen Sie die von Ihnen erstellten URL-Objekte explizit, oder lassen Sie den Server entscheiden? Wenn Sie sie benennen, verwenden Sie PUT. Wenn Sie den Server entscheiden lassen, verwenden Sie POST.
• PUT ist idempotent, d. h. wenn Sie ein Objekt zweimal PUTen, hat das keine Auswirkungen. Das ist eine gute Eigenschaft, deshalb würde ich PUT verwenden, wenn es möglich ist.
• Mit PUT können Sie eine Ressource mit der gleichen Objekt-URL aktualisieren oder erstellen.
• Mit POST können 2 Anfragen gleichzeitig eingehen, die Änderungen an einer URL vornehmen, und sie können verschiedene Teile des Objekts aktualisieren.

Ein Beispiel:

Ich habe das Folgende als Teil einer anderen Antwort auf SO zu diesem Thema geschrieben:

POST:

Wird verwendet, um eine Ressource zu ändern und zu aktualisieren

POST /questions/ HTTP/1.1 Host: www.example.com/

Beachten Sie, dass das Folgende ein Fehler ist:

POST /questions/ HTTP/1.1 Host: www.example.com/

Wenn die URL noch nicht erstellt ist, sollten Sie sollten Sie nicht POST verwenden, um sie zu erstellen während Sie den Namen angeben. Dies sollte zu einem 'resource not found' Fehler führen weil nicht existiert noch nicht. Sie sollten die PUT Ressource zuerst auf den Server stellen.

Sie könnten aber auch etwas tun wie dies tun, um eine Ressource per POST zu erstellen:

POST /Fragen HTTP/1.1 Host: www.example.com/

Beachten Sie, dass in diesem Fall die Ressource Name nicht angegeben ist, die neuen Objekte URL-Pfad zurückgegeben werden würde.

PUT:

Wird verwendet, um eine Ressource zu erstellen, oder sie zu überschreiben. Dabei geben Sie die Ressourcen neue URL.

Für eine neue Ressource:

PUT /questions/ HTTP/1.1 Host: www.example.com/

Um eine bestehende Ressource zu überschreiben:

PUT /questions/ HTTP/1.1 Host: www.example.com/

Verwenden Sie POST zum Erstellen und PUT zum Aktualisieren. So wird es jedenfalls in Ruby on Rails gehandhabt.

PUT    /items/1      #=> update
POST   /items        #=> create

REST ist ein sehr hochrangiges Konzept. In der Tat wird HTTP nicht einmal erwähnt!

Wenn Sie Zweifel haben, wie REST in HTTP implementiert werden kann, können Sie jederzeit einen Blick auf die Atom Publication Protocol (AtomPub) Spezifikation werfen. AtomPub ist ein Standard für das Schreiben von RESTful Webservices mit HTTP, der von vielen HTTP- und REST-Koryphäen entwickelt wurde, mit einigen Beiträgen von Roy Fielding, dem Erfinder von REST und (Mit-)Erfinder von HTTP selbst.

Vielleicht können Sie AtomPub sogar direkt verwenden. Obwohl es aus der Blogging-Community hervorgegangen ist, ist es keineswegs auf das Blogging beschränkt: Es ist ein allgemeines Protokoll für die REST-Interaktion mit beliebigen (verschachtelten) Sammlungen beliebiger Ressourcen über HTTP. Wenn Sie Ihre Anwendung als eine verschachtelte Sammlung von Ressourcen darstellen können, dann können Sie AtomPub verwenden und müssen sich keine Gedanken darüber machen, ob Sie PUT oder POST verwenden, welche HTTP-Statuscodes zurückgegeben werden sollen und all diese Details.

Dies ist, was AtomPub über die Erstellung von Ressourcen zu sagen hat (Abschnitt 9.2):

Um Mitglieder zu einer Collection hinzuzufügen, senden Clients POST-Anfragen an die URI der Collection.