RESTful löschen Strategie

Lasst uns sagen, dass ich eine Ressource, die zwei unterschiedliche Verhaltensweisen haben können, wenn löschenRESTful löschen Strategie

Die Ressource gelöscht wird aufgerufen wird.
Die Ressource wird in den Papierkorb verschoben.

Wie würde es in einer REST-konformen Weise modellieren?

Ich dachte an die folgende Lösung:

DELETE /myresource

die Ressource in den Papierkorb bewegt (Standardverhalten)

DELETE /myresource?force-delete=true

Kräfte auf die Ressource löschen.

Ist das REST-konform? Ich habe noch nie Abfrageparameter in der URL beim Aufruf von DELETE gesehen, ist das OK?

Quelle

2009-02-04 LiorH

Eine reine REST-Strategie sollte nicht wechselnde Ressourcen bevorzugen. Meiner Meinung nach ändern Sie die Ressource nicht, indem Sie einen Parameter hinzufügen, also klingt es für mich nach einer guten Strategie.

Wenn Sie so die gleiche Aktion durchzuführen waren:

DELETE /myresource.force

, die wie eine andere Ressource handeln würde, die nicht optimal wäre.

Quelle

2009-02-04 17:11:30 ern

Dies bricht die "Regeln" von REST, indem Sie eine andere Ressource adressieren. Gleichzeitig bieten /myresource.json und /myresource.xml verschiedene Formate der gleichen Daten an (benutzen Sie Ihre Header akzeptieren, Leute!), Aber das wird nicht in absehbarer Zeit verschwinden. –

Dies ist nicht "REST", Sie führen Aktionen auf RPC-Weise aus. – thecoshman

Warum nicht? Sie übergeben bereits einen Parameter, um die Ressource zu identifizieren. Senden Sie eine andere, um eine andere Vorgehensweise festzulegen. IMO, es ist perfekt RESTful.

Quelle

2009-02-04 17:11:08 Swanand

Ihre Idee ist in Ordnung, aber ich denke, eine benutzerdefinierte Anfrage Header wäre ein wenig geeigneter. Abfrageparameter sind besser für Parameter geeignet.

Eine benutzerdefinierte Request-Header würde wie folgt aussehen:

DELETE /myresource 
X-Really-Delete: Yup

Quelle

2009-02-05 03:07:12

Sie auch 2. als POST-Anforderung statt DELETE implementieren könnte.

POST /myresource 

recycle-bin=true...

Wie in alles, was Sie tun, ist die Aktualisierung der Ressource, um anzuzeigen, dass es in der recycle-bin ist.

EDIT: geändert Methode PUT-POST gegeben einer PUT müssen einen vollständigen Ersatz (oder zusätzlich) der Ressource einzuschließen, während hier klar sind wir nur einen Teil der Ressource zu aktualisieren.

Quelle

2009-02-05 03:18:40 rojoca

Ich würde gegen Ihren Wechsel von PUT zu POST argumentieren. POST dient zum Erstellen von Inhalten, PUT ist für Änderungen; Das ganze OP macht wirklich eine Ressource mit einem bestimmten Wert, dh sie zu aktualisieren. – thecoshman

@thecoshman PUT ist create or replace, bei dem die gesamte Entität in der Anforderung eingeschlossen sein muss. Änderungen können über die PATCH-Methode vorgenommen werden, haben jedoch nur eingeschränkte Unterstützung. – rojoca

erh ... etwas. PUT kann verwendet werden, um Inhalte zu erstellen, wie auch POST. Der Unterschied besteht darin, dass Sie PUT bei einem bestimmten URI erstellen, während Sie beim POST den Server auffordern, herauszufinden, unter welchem URI er gespeichert werden soll. PUT kann auch verwendet werden, um eine Ressource zu ersetzen. Sie haben recht, wenn Sie sagen, dass PATCH die richtige Methode ist, um ein kleines Update wie dieses zu machen. In Ermangelung einer geeigneten Unterstützung wäre es die "richtige" Lösung, die vollständige Ressource abzurufen, sie zu aktualisieren und die vollständige Aktualisierungsressource auf dem Server auf denselben URI zu setzen. – thecoshman

DELETE sollte das Element löschen, keine Fragen gestellt.

Leider gibt es keine "MOVE" Anfrage in HTTP. POST ist normalerweise zum Erstellen von Inhalten gedacht, PUT ist mehr Modifikationen.

Also würde ich vorschlagen, dass Sie etwas wie PUT /myresource mit irgendeiner Form von Metadaten oder einer JSON-Zeichenkette entlang der Linien von { "recycle":"true" } tun, um anzuzeigen, dass Sie es "recyceln" wollen.

Quelle

2013-06-27 15:19:45 thecoshman

RESTful löschen Strategie

Antwort

Verwandte Themen