ch entwerfe derzeit die API für eine vorhandene PHP-Anwendung und untersuche zu diesem Zweck REST als sinnvollen Architekturansat

ch glaube, ich habe ein vernünftiges Verständnis für die Schlüsselkonzepte, aber ich kämpfe darum, jemanden zu finden, der sich mit Objekthierarchien und REST befass

Hier ist das Problem ...

In der Geschäftsobjekthierarchie [application] haben wir:

Users 
 L which have one-to-many Channel objects
 L which have one-to-many Member objects

In der Anwendung selbst verwenden wir einen Lazy Load-Ansatz, um das User-Objekt nach Bedarf mit Arrays dieser Objekte zu füllen. Ich glaube in OO-Begriffen, dass dies eine Objektaggregation ist, aber ich habe verschiedene Namensinkonsistenzen gesehen und möchte keinen Krieg um die genaue Namenskonvention beginnen.

Betrachten Sie jetzt, dass ich einige lose gekoppelte Objekte habe, die ich je nach Anwendungsbedarf möglicherweise / möglicherweise nicht auffüllen kann.

us einer REST-Perspektive versuche ich herauszufinden, wie der Ansatz aussehen soll. Hier ist mein aktuelles Denken (unter Berücksichtigung von GET nur für den Moment):

Option 1 - Füllen Sie die Objekte vollständig aus:

GET api.example.com/user/{user_id}

Lesen Sie das User-Objekt (Ressource) und geben Sie das User-Objekt mit allen möglichen Channel- und Member-Objekten zurück, die vorab geladen und codiert wurden (JSON oder XML).

PROS: Objektanzahl reduzieren, kein Durchlaufen von Objekthierarchien erforderlich
CONS: Objekte müssen vollständig gefüllt sein (teuer)

Option 2 - Füllen Sie das primäre Objekt und fügen Sie Links zu den anderen Objektressourcen hinzu:

GET api.example.com/user/{user_id}

Lesen Sie das Benutzerobjekt (Ressource) und geben Sie das Benutzerobjekt Benutzerdaten ausgefüllt und zwei Listen zurück.

Jede Liste verweist auf die entsprechende (Unter-) Ressource, d. H.

api.example.com/channel/{channel_id}
api.example.com/member/{member_id}

Ich denke, dies liegt in der Nähe (oder genau) der Implikationen von Hypermedia - der Client kann die anderen Ressourcen erhalten, wenn er möchte (solange ich sie vernünftig tagge).

PROS: Client kann wählen, ob die Untergebenen geladen werden sollen oder auf andere Weise, um die Objekte besser als REST-Ressourcen zu trennen.
CONS: weitere Reise erforderlich, um die sekundären Ressourcen zu erhalten

Option 3 - Rekursive Abfragen aktivieren

GET api.example.com/user/{user_id}

Lesen Sie das Benutzerobjekt und fügen Sie Links zu Listen der Unterobjekte hinzu, d. H.

api.example.com/user/{user_id}/channels
api.example.com/user/{user_id}/members

der / channels-Aufruf würde eine Liste der Kanalressourcen in der Form (wie oben) zurückgeben:

api.example.com/channel/{channel_id}

PROS: Primäre Ressourcen legen fest, wohin sie gehen müssen, um die Subodinaten abzurufen, aber nicht, was sie sind (restvoller?). Keine Anforderung, die Subordinaten im Voraus abzurufen. Die untergeordneten Listengeneratoren (/ channels und / members) stellen Schnittstellen bereit (Methoden wie). macht die Antwort mehr Service wie.
CONS: Drei Aufrufe sind jetzt erforderlich, um das Objekt vollständig zu füllen.

Option 4 - Objektdesign für REST @ (neu) betracht

Ich verwende die [vorhandene] Anwendungsobjekthierarchie erneut und versuche, sie auf REST anzuwenden - oder möglicherweise direkter, stelle eine API-Schnittstelle dafür bereit.

Vielleicht sollte die REST-Objekthierarchie anders sein, oder das neue REST-Denken legt Einschränkungen des vorhandenen Objektdesigns offen.

Irgendwelche Gedanken zu den oben genannten begrüßt.

Danke vielmal

Paul