REST-API-Design zum Klonen einer Ressource

Question

Ich schreibe ein YAML-Dokument mithilfe von Swagger, um eine RESTful-API-Methode zum Klonen einer Ressource zu entwerfen. Ich habe ein paar Optionen und weiß nicht, welches das Beste wäre. Kann bitte jemand beraten?

Optionen:

1. Verzicht auf die Verantwortung gegenüber dem Verbraucher das Ressourcenobjekt des Klonens (wo die Verbraucher Werte Eigenschaften auf ein neues Objekt zuweist und erstellt dann ein neues Objekt), müsste der Prozess bestehen aus zwei Anforderungen an die API: ein GET für eine Ressource für das Quellobjekt und dann ein POST für diese Ressource zum Erstellen der neuen. Das fühlt sich an, als hätte der Verbraucher zu viel Verantwortung.
2. Verwenden der WebDAV-HTTP-Erweiterungen, die eine COPY-Methode (see here) bereitstellt. Es scheint, dass dies genau das ist, was ich zum Klonen möchte. Aber ich möchte so viel wie möglich
3. POSTen zu/{} Ressource den Standardmethoden bleiben? ResourceIdToClone = {id} wo resourceIdToClone einen optionalen Parameter ist. Dies würde zu einem API-Pfad führen, den ich bereits zum Erstellen der Ressource habe, wo ich dem POST-Hauptteil ein Schema hinzufüge. Es würde bedeuten, einen POST nach/{resource}/zum Erstellen und Klonen zu verwenden, was SRP verletzen würde.
4. Hinzufügen einer neuen Ressource namens 'CloneableResource' und Ausführen eines POST an/CloneableResource/{resource_type}/{resource_source_id}. Für das Beispiel des Klonens eines Schafs würden Sie einen POST an/CloneableResource/Sheep/10 vornehmen. Auf diese Weise wäre es möglich, bei der Verwendung der Standard-HTTP-Methoden zu bleiben, da es keinen Konflikt mit anderen Ressourcenpfaden (oder SRP-Verletzung) geben würde. Allerdings würde ich der Domain einen neuen und potenziell überflüssigen Typ hinzufügen. Ich kann auch nicht an ein Szenario denken, wenn ein Verbraucher etwas anderes als ein POST zu dieser Ressource durchführen möchte, so scheint es wie ein Code-Geruch für mich.
5. Ein GET gegen/Ressource/{ID}? Methode = Klon. Einer der Vorteile hier ist, dass keine zusätzliche Ressource erforderlich ist und durch einen einfachen optionalen Querystring-Parameter bestimmt werden kann. Ich bin mir bewusst, dass eines der Risiken hier darin besteht, dass es gefährlich sein kann, Post- oder Löschfunktionen mit einer GET-Methode bereitzustellen, wenn sich die URL auf einer Webseite befindet, da sie von einer Suchmaschine gecrawlt werden kann.

Danke für jede Hilfe!

Answer 1

Beeinflusst von den Projektanforderungen und den Präferenzen der Mitglieder in meinem Team, wird Option 1 uns in dieser Phase am besten dienen.

• Konform zu den Standard-HTTP-Methoden werden meine API
• Es wird ein einziger, konsistenter Ansatz vereinfachen und klären, um eine Ressource zu klonen. Dies überwiegt das Problem, das ich beim Festlegen der Klonarbeit für den Verbraucher habe.

Answer 2

Wenn Sie eine Ressource kopieren möchten, dann ist COPY eine naheliegende Wahl.

(und ja, es wäre gut, die Definitionen von COPY und MOVE aus RFC 4918 zu ziehen, um sie von WebDAV zu entwirren).

Answer 3

Die meisten dieser Optionen sind eine sehr gute Wahl. Vieles davon ist nur Ihre Stilwahl am Ende. Hier sind meine Kommentare zu jeder Ihrer Optionen.

1. Verzicht auf die Verantwortung der Klonierung des Ressource-Objekt für den Verbraucher
   Im Allgemeinen ich nicht wirklich ein Problem mit dieser Lösung haben. Diese Option ist für einen Benutzer sehr einfach zu verstehen und zu implementieren. Es könnte besser sein, als eine proprietäre Klonfunktionalität zu entwickeln, die Ihre Benutzer lernen müssen.

2. über die HTTP-Erweiterungen, die WebDAV eine Kopie Methode liefert
   I als auch zu den Standardverfahren haften mag. Ich würde COPY nicht verwenden, aber ich würde nicht entsetzt sein, wenn Sie es taten.

3. POSTen zu/{} Ressource? ResourceIdToClone = {id}
   Dies ist eine ganz gute Lösung. Aus REST-Sicht haben Sie nicht wirklich einen Konflikt mit dem Rest Ihrer API. Der URI mit einem Abfrageparameter identifiziert eine andere Ressource als den URI ohne den Abfrageparameter. Abfrageparameter sind eine URI-Funktion zum Identifizieren von Ressourcen, auf die Sie nicht hierarchisch verweisen können. Es kann jedoch schwierig sein, diese in Ihrem Code zu trennen, da die meisten REST-Frameworks funktionieren. Sie könnten etwas Ähnliches tun, außer mit einem hierarchischen URI wie /{resource}/clone. Sie könnten diese URI POST und übergeben Sie die resource_source_id in den Körper.

4. Hinzufügen einer neuen Ressource namens ‚CloneableResource‘ und Durchführen einer POST/CloneableResource/{RESOURCE_TYPE}/{resource_source_id}
   Es ist nichts falsch mit diesem Ansatz von einem REST Standpunkt, aber ich denke, das Hinzufügen eines neuen Typ ist beides unnötig und verstopft die API. Allerdings stimme ich Ihrer Intuition nicht zu, da es ein Problem mit einer Ressource geben könnte, die nur eine POST-Operation hat. Es passiert. In der realen Welt passt nicht alles gut in GET, PUT oder DELETE.

5. A GET gegen/Mittel/{id}? Method = Klon
   Dies ist die einzige Möglichkeit, die 5, die ich nicht gutheißen kann. Es scheint aus Ihrer Beschreibung, dass Sie bereits verstehen, warum dies eine schlechte Idee ist, so dass ich nicht sicher bin, warum Sie darüber nachdenken. Alles, was Sie tun müssen, um dies zu einer guten Lösung zu machen, ist jedoch, GET zu POST zu ändern. Es wird dann der Lösung Nr. 3 sehr ähnlich. Der URI könnte auch hierarchisch sein, anstatt einen Abfrageparameter zu verwenden. POST /resource/{id}/clone würde genauso gut funktionieren.

Ich hoffe, das war hilfreich. Viel Glück mit Ihrer Entscheidung.