PUT vs. POST in REST

Overall:

Zowel PUT als POST kunnen worden gebruikt voor het aanmaken.

Je moet je afvragen "what are you performing the action to?" om te onderscheiden wat je zou moeten gebruiken. Laten we aannemen dat je een API aan het ontwerpen bent voor het stellen van vragen. Als je POST wilt gebruiken dan zou je dat doen naar een lijst met vragen. Als u PUT wilt gebruiken dan zou u dat doen voor een bepaalde vraag.

Goed beide kunnen worden gebruikt, dus welke moet ik gebruiken in mijn RESTful ontwerp:

Je hoeft niet zowel PUT als POST te ondersteunen.

Welke je gebruikt is aan jou. Maar vergeet niet de juiste te gebruiken, afhankelijk van het object waarnaar je verwijst in het verzoek.

Enkele overwegingen:

• Geef je URL objecten die je maakt expliciet een naam, of laat je de server beslissen? Als je ze een naam geeft, gebruik dan PUT. Als je de server laat beslissen, gebruik dan POST.
• PUT is idempotent, dus als je een object twee keer PUT, heeft dat geen effect. Dit is een mooie eigenschap, dus ik zou PUT gebruiken als het mogelijk is.
• Je kunt een resource updaten of aanmaken met PUT met dezelfde object URL
• Met POST kun je 2 verzoeken tegelijkertijd binnen laten komen om een URL aan te passen, en ze kunnen verschillende delen van het object updaten.

Een voorbeeld:

Ik schreef het volgende als onderdeel van een ander antwoord op SO betreffende dit:

POST:

Gebruikt om een bron te wijzigen en bij te werken

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

Merk op dat het volgende een fout is:

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

Als de URL nog niet is aangemaakt, moet je moet je geen POST gebruiken om hem aan te maken terwijl je de naam opgeeft. Dit zou resulteren in een 'resource not found' error omdat nog niet bestaat nog niet bestaat. Je moet de resource eerst op de server zetten.

Je zou echter iets kunnen doen als dit om een resource te maken met POST:

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

Merk op dat in dit geval de resource naam niet is gespecificeerd, de nieuwe objecten URL pad zou worden teruggegeven aan u.

PUT:

Gebruikt om een resource te maken, of te overschrijven. Terwijl u de resources nieuwe URL.

Voor een nieuwe resource:

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

Om een bestaande resource te overschrijven:

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

Gebruik POST om te creëren, en PUT om te updaten. Dat's hoe Ruby on Rails het doet, in ieder geval.

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

REST is een zeer hoog niveau concept. In feite wordt HTTP er zelfs helemaal niet in genoemd!

Als je twijfelt over hoe je REST in HTTP kunt implementeren, kun je altijd een kijkje nemen in de [Atom Publication Protocol (AtomPub)][1] specificatie. AtomPub is een standaard voor het schrijven van RESTful webservices met HTTP die is ontwikkeld door vele HTTP en REST grootheden, met enige inbreng van Roy Fielding, de uitvinder van REST en (mede-)uitvinder van HTTP zelf.

In feite zou je zelfs AtomPub rechtstreeks kunnen gebruiken. Hoewel het is voortgekomen uit de blogging gemeenschap, is het op geen enkele manier beperkt tot blogging: het is een generiek protocol voor REST-achtige interactie met willekeurige (geneste) verzamelingen van willekeurige bronnen via HTTP. Als je je applicatie kunt voorstellen als een geneste verzameling van bronnen, dan kun je gewoon AtomPub gebruiken en je geen zorgen maken over of je PUT of POST moet gebruiken, welke HTTP Status Codes je moet retourneren en al die details.

Dit is wat AtomPub te zeggen heeft over het aanmaken van resources (sectie 9.2):

Om leden aan een Collection toe te voegen, sturen clients POST requests naar de URI van de Collection.