REST-Ressourcenpfadentwurf

Ich entwickle einen REST-Service und versuche, die Konventionen und Richtlinien von Doctor Roy Fielding einzuhalten.

Ich stelle mir meinen Service als einen Endpunkt vor, der eine Reihe von Ressourcen verfügbar macht. Eine Ressource wird durch einen URI identifiziert, und API-Clients können Ressourcen mithilfe der HTTP-Semantik manipulieren (d. H. Verschiedene HTTP-Verben werden den entsprechenden Operationen über URIs zugeordnet).

Richtlinien besagen, dass diese URIs hierarchisch definiert werden sollten, um die Objekthierarchie widerzuspiegeln. Dies ist beim Erstellen von Ressourcen nützlich, da wir auf dem Backend die Daten benötigen, um die Erstellungsoperation auszuführen. Bei weiteren Manipulationen werden jedoch viele der in der URI enthaltenen Informationen nicht einmal vom Service verwendet, da im Allgemeinen die Ressourcen-ID ausreicht, um das Operationsziel eindeutig zu identifizieren.

Ein Beispiel: Stellen Sie sich eine API vor, die die Erstellung und Verwaltung von Produkten offenlegt. Bedenken Sie auch, dass ein Produkt mit einer Marke verbunden ist. Bei der Erstellung ist es sinnvoll, dass die folgende Aktion ausgeführt wird: HTTP POST / Brand / {brand_id} / Product [Body, der die für die Erstellung des Produkts erforderlichen Eingaben enthält]

Die Erstellung gibt ein HTTP 201 zurück, das mit einem Standortheader erstellt wurde, der den Standort des neu erstellten Produkts anzeigt.

Bei weiteren Manipulationen können Clients folgendermaßen auf das Produkt zugreifen: HTTP PUT / Brand / {Marken-ID} / Product / {Produkt-ID} HTTP DELETE / Brand / {Marken-ID} / Product / {Produkt-ID} etc

Da die Produkt-ID im Produktumfang jedoch universell ist, können die folgenden Manipulationen wie folgt durchgeführt werden: / Product / {product_id} Ich behalte das Präfix / Brand / {brand_id} nur aus Kohärenzgründen. Tatsächlich wird die Marken-ID vom Service ignoriert. Halten Sie dies für eine bewährte Vorgehensweise und für sinnvoll, um eine klare, eindeutige ServiceInterface-Definition beizubehalten? Was sind die Vorteile davon, und ist dies überhaupt der richtige Weg?

Über Hinweise zu bewährten Methoden für die URI-Definition würde ich mich freuen.

Danke im Voraus

Antworten auf die Frage(2)

Ihre Antwort auf die Frage