Nehmen wir an, ich wollte eine REST-API entwerfen, die von Songs, Alben und Künstlern handelt (eigentlich tue ich das, wie 1312414 Leute vor mir).
Eine Song-Ressource ist immer mit dem Album verknüpft, zu dem sie gehört. Umgekehrt ist die Album-Ressource allen Songs zugeordnet, die sie enthält. Die Verknüpfungen werden in den Ressourcendarstellungen durch Links ausgedrückt.
Als solche würden die Darstellungen in etwa so aussehen:
%Vor%Da ich möchte, dass dies gilt (vielleicht liegt das Problem im "Gegebenen"), wie kann ich dann meine API so gestalten, dass die Erstellung eines Albums oder einer Song-Ressource keine Nebenwirkungen auf bereits existierende hat Titel oder Album-Ressourcen?
Dies ist eine Art Hühnereiproblem. Wenn ich zuerst eine Song-Ressource erstelle (POST / songs /) und dann eine Album-Ressource (POST / albums /) erstelle, wird die Song-Ressource als Teil der Album-Erstellung modifiziert (was nach REST-Prinzipien schlecht ist), weil die Assoziation zwischen den beiden Ressourcen wird auf dem Server aktualisiert. Ebenso für das Szenario, in dem ich das Album zuerst erstelle, das Lied als zweites.
Ich denke, ich könnte das ganze Problem vermeiden, indem ich die Nebeneffekte auf dem Server vermeide und die Last der Verwaltung der bidirektionalen Beziehungen zum Client überlasse.
Ich möchte auch nicht, dass Album und Songs als Ganzes atomar erstellt werden.
Das Einzige, woran ich gerade denken kann, ist, den oben erwähnten Nebeneffekt in die Semantik meiner API aufzunehmen, indem ich auf eine Ressourcenerstellung mit einer Repräsentation antworte, die eine Liste von Links zu Ressourcen enthält, die als Ergebnis modifiziert wurden der Anfrage. Das macht den Nebeneffekt zwar explizit, aber trotzdem nicht erholsam.
Nichts über REST besagt, dass die Manipulation des Zustands einer Ressource den Status einer anderen Ressource nicht ändern kann. Über das, was REST am nächsten kommt, ist die Vorstellung von idempotenten Aktionen, die nur sagen, dass das Wiederholen derselben denselben Zustand ergibt.
In Ihrem Fall gibt es also nichts an sich Inkorrektes, wenn sich eine Song Ressource effektiv zu einer Album Ressource hinzufügen kann. Es ist auch nicht von Natur aus falsch, dass eine Album Ressource sagen kann, dass eine Song Ressource ein Teil davon ist.
Nun, in Anbetracht Ihrer geschäftlichen Anforderungen, möchten Sie vielleicht entweder a.) Ändern, wie Sie Songs / Alben darstellen oder b.) Lassen Sie Songs / Alben in einer m / m-Weise statt 1/1 in Beziehung stehen. Der Grund dafür ist, dass Sie abhängig davon, wie Sie Ihre Daten strukturieren und Ressourcen (dh adressierbare Einheiten) in Ihrem System auswählen, unterschiedliche Datenbeziehungen modellieren, und dies ist meiner Meinung nach der Kern des Problems, dem Sie gegenüberstehen .
Wenn Songs und Albums Ressourcen in Ihrem System trennen, erfordert die Durchsetzung restriktiverer Beziehungen wie 1/1 anstelle von m / m viel mehr Arbeit und Spezifizierung in Ihren Inhaltstypen. Sie müssen die Fälle behandeln, in denen zwei verschiedene Alben beide denken, dass sie ein einzelnes Lied enthalten, aber eine 1/1 Beziehung erlaubt das nicht.
Wenn Sie ein Album -Objekt explizit enthalten oder eigenes die Song -Objekte haben, gibt es weniger Probleme, da ein Album nur manipulieren kann Es sind eigene Songs und nicht die eines anderen Album . Dieses ändert jedoch das Datenmodell, da Songs nicht mehr erstklassige Bürger sind, sondern stattdessen unterhalb des Albums, das sie besitzt.
Dies ist der Schlüsselpunkt des ganzen Problems ... Sie müssen entscheiden, wem die Beziehung gehört .
Es ist nichts falsch mit beiden Seiten ( Album und Song ), die es besitzen. Dies funktioniert perfekt für eine m / m-Beziehung, aber für eine 1/1-Beziehung, die entweder viel mehr Verwaltungsaufwand erfordert (d. H. Etwas anderes besitzt tatsächlich die Beziehung).
Wenn Sie jedoch eine 1/1-Beziehung ohne den gesamten Aufwand möchten, müssen Sie eins der beteiligten Entitäten besitzen, was bedeutet, dass es nur eins Weg, um es zu ändern ... durch die besitzende Einheit.
Tags und Links rest api-design