REST PUT vs POST mit UUID

Question

Wenn ich ein UUID bin mit dem Unternehmen als Teil meiner URI meines REST-Endpunkt zu identifizieren:

/entities/<uuid>/ 

und dass UUID vom Client generiert wird, wenn neue Objekte zu schaffen, ist gibt es eine Best Practice soweit PUT vs POST zu verwenden? Mit anderen Worten, die UUID wird vom Client im Gegensatz zum Server generiert.

Wenn ich PUT verwenden würde, wird erwartet, dass die Nachrichtennutzlast auch die UUID enthält? In diesem Fall enthalten sowohl die Nachricht als auch der URI, der die Entität identifiziert, das UUID.

Für spec finden: die REST RFC

Answer 1

Da Sie (der Kunde) bereits die UUID wissen, würde ich sagen PUT ist die beste Praxis, und Sie brauchen nicht UUID in der Nutzlast enthalten. Zugegeben, PUT vs POST ist etwas kontrovers und das Lesen und erneutes Lesen der RFC ist nicht völlig klar für mich. Aber ich denke, das Vorhergehende ist Orthodoxie.

Siehe PUT vs POST in REST für eine nette Diskussion.

Answer 2

Der Hauptunterschied zwischen POST und PUT:

POST wird verwendet, um neue Einheiten anzuhängen. POST ist nicht idempotent. Das bedeutet, wenn Sie eine POST-Anfrage zehn Mal senden, erstellen Sie zehn verschiedene Entitäten. Normalerweise sollten Sie den Antwortcode 201 (Created) an die POST-Anforderung senden, die mit dem Location-Header verbunden ist, der auf die URL der neu erstellten Ressource zeigt. In Ihrem Fall schlage ich vor, wie

POST /entities/ HTTP/1.1 
Content-Type: application/json 
{ 
    UUID: <UUID>.. 
    OtherStuff: ... 
} 

Antwort auf URL STHM POST:

HTTP/1.1 201 Created 
Location: http://www.myREST/entities/<uuid>/ 

PUT Anfrage verwendet wird, bestehenden Zustand zu ändern. PUT ist idempotent. Normalerweise erhalten Sie 200 (OK) Antwortcode.

Sie müssen UUID in PUT/POST-Nutzdaten enthalten. UUID ist Teil der Darstellung Ihrer Ressource. PUT und POST übertragen beide Repräsentationen auf den REST-Server, um den Ressourcenstatus zu ändern/anzufügen.

BTW sollten Sie nicht URI Begriff in REST verwenden. URI ist sthm, das keine Repräsentation hat, obwohl URL immer Repräsentation hat.

Answer 3

Verstehen Sie den Unterschied zwischen PUT und POST.

PUT soll Ressource (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6) ersetzen, auf die der URI mit einem neuen verweist. Und es ist idempotent, d.h. wie oft Sie es mit derselben Nutzlast aufrufen, das Ergebnis ist das gleiche; Es wird dieselbe Ressource über den URI verfügbar machen.

Also, wenn die Ressource nicht dort ist, wird bereits eine neue erstellt. Selbst in diesem Fall ist das Ergebnis dasselbe, d. H. Es wird dieselbe Ressource über den URI verfügbar gemacht.

POST bedeutet, eine Unterressource (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) für die Ressource zu erstellen, auf die der URI zeigt.Wenn die Ressource eine Liste ist, fügt sie ein Element hinzu. Wenn es ein Element ist, dann sollte es etwas zum Objekt hinzufügen, ein Attribut kann sein.

Also, im Idealfall, wenn das Element, auf das der URI verweist, nicht verfügbar ist, sollte es eine Fehlerbedingung sein. Kann ein "404" sein. Beim POST geht es darum, eine vorhandene Ressource hinzuzufügen.

Kommen zu Ihrer Frage, ist es am besten, POST mit "/ entities /" als URI wie in der obigen Beschreibung zu verwenden. Sie sollten keine nicht vorhandene Ressourcen-UUID im URI mit der POST-Methode verwenden. Wenn Sie PUT verwenden, verwenden Sie "/ entities /".

POST /entities/ HTTP/1.1 
Content-Type: application/json 
{ 
    UUID: <UUID>.. 
    OtherStuff: ... 
} 

PUT /entities/<UUID> HTTP/1.1 
Content-Type: application/json 
{ 
    UUID: <UUID>.. 
    OtherStuff: ... 
} 

Antwort sollte

HTTP/1.1 201 Created 
Location: http://www.examples.com/entities/<uuid>/ 

gleichen sein, obwohl PUT idempotent ist, aber wenn der PUT Verfahren wieder verwendet wird, dann sollte es 200 oder 204 in Reaktion verwenden.

Ihre zweite Frage: Idealerweise sollte das vollständige Ressourcendetail in der PUT-Nutzlast und nicht nur in der URI enthalten sein.