In /core/http-methods staat dat een PUT gebruikt mag worden voor een Update _en indien de resource niet bestaat voor een Create. Ik ben voorstander om die Create niet toe te staan. Een PUT naar een resource die niet bestaat moet een HTTP-404 (Not Found) opleveren omdat de resource met de aangeven {id} niet bestaat.
Wanneer een client een PUT naar een (voor hem) niet bestaande resource kan er van alles aan de hand zijn waardoor er onbedoeld gedrag veroorzaakt wordt als je die naar een Create vertaalt:
- de resource instance kan door een ander proces/andere client bewust verwijderd zijn (wat de client die de PUT uitvoert niet weet) en wordt dan weer opnieuw aangemaakt
- de resource instance bestaat nog maar de client die de PUT uitvoert heeft er geen rechten (meer) op dus ziet 'm niet. Je zou dit met een HTTP-403 kunnen afvangen maar een 404 is ook legitiem als je de client überhaupt niet op de hoogte wil brengen van het bestaan van de resource war ie geen recht op heeft
- de client geeft om welke reden dan ook zelf en verkeerd id op in zjin PUT-request. Hij dénkt dat ie een bestaande resource instance vervangt maar er wordt een nieuwe resource instance aangemaakt. In een
POST ../orders operation in een webshop heb je dan zomaar dubbel besteld zonder dat je het door hebt.
In /core/http-methods staat dat een
PUTgebruikt mag worden voor een Update _en indien de resource niet bestaat voor een Create. Ik ben voorstander om die Create niet toe te staan. EenPUTnaar een resource die niet bestaat moet een HTTP-404 (Not Found) opleveren omdat de resource met de aangeven{id}niet bestaat.Wanneer een client een PUT naar een (voor hem) niet bestaande resource kan er van alles aan de hand zijn waardoor er onbedoeld gedrag veroorzaakt wordt als je die naar een Create vertaalt:
POST ../ordersoperation in een webshop heb je dan zomaar dubbel besteld zonder dat je het door hebt.