RESTful Design scheint flache oder flache strukturierte Repräsentationen zu befürworten (zumindest wenn Ressourcen als XML dargestellt werden). Eine Ressourcendarstellung sollte nur die Ressource enthalten, die der URI identifiziert. Ich frage mich, wann es sinnvoll ist, die Ressourcen der Ressource in der übergeordneten Ressource darzustellen.
Um dies näher auszuführen, bedenken Sie Folgendes: Das Unternehmen kann mehrere Mitarbeiter haben. Normalerweise würde diese Situation wahrscheinlich als zwei getrennte Ressourcen, Unternehmen und Mitarbeiter, gestaltet werden, wobei der Mitarbeiter die Unterressource des Unternehmens wäre.
%Vor%Bei diesem URI-Design sollte die Unternehmensdarstellung Links zu ihren Mitarbeitern enthalten, aber die XML-Darstellung würde vermutlich keine Mitarbeiter enthalten.
Daher macht es Sinn, gegenwärtige Unterelemente durch das Elternteil darzustellen? Und gibt es eine Situation, in der es sinnvoll wäre, den Unterpunkt only über seine Eltern zu präsentieren. Ich meine, dass es überhaupt keine URI für Sub-Items geben würde. Sie konnten nur durch die Elternressource erreicht werden.
%Vor%Ist es sinnvoll, nur eine Methode für den Zugriff auf eine Ressource anzubieten: Wenn ein Elternteil seine Unterelemente aufdeckt, kann es dann auch einen expliziten URI für die Unterelemente geben? Also, wenn das XML des Unternehmens Mitarbeiter des Unternehmens enthält, würde es Sinn machen, / Unternehmen / acme / Mitarbeiter URI anzubieten, obwohl Sie die gleichen Informationen über die Unternehmensressourcen erhalten können?
Wenn die Unterressource nur im Kontext des übergeordneten Elements sinnvoll ist, dann sollte sie innerhalb des übergeordneten Elements verschachtelt zurückgegeben werden. Zum Beispiel macht ein <li> -Element in HTML als Unterressource alleine keinen Sinn.
Wenn eine Ressource jedoch eigenständig sein kann und Sie eine Ressource unabhängig von anderen Ressourcen bearbeiten möchten, sollte sie einen eigenen URI haben. Auf diese Weise können Sie POST oder PUT an diese Ressource senden, ohne andere verwandte Ressourcen zu beeinträchtigen, und ohne sie auf den Server zurückzuspeichern. Wenn Sie alles vom Elternteil manipulieren müssen, denken Sie darüber nach, was passiert, wenn eine Person ein GET ausführt, einen Unterpunkt ändert und dann einen PUT der gesamten Sache mit diesem Unterpunkt ändert; Was ist, wenn jemand anderes einen der anderen in der Zwischenzeit geändert hat? Dann müssen Sie Locks und transaktionale Semantiken hinzufügen, die die gesamte Statuslosigkeit von REST besiegen.
Für GET-Anfragen ist es wahrscheinlich eine gute Idee, eine Art von Massenabfrageschnittstellen zu haben, durch die ein Client eine große Anzahl von Ressourcen gleichzeitig erhalten kann; Eine neue HTTP-Anfrage für jede Ressource zu erstellen kann sehr lange dauern, da dies für jeden GET einen neuen Umlauf über das Netzwerk bedeutet. Es kann auch sinnvoll sein, Bulk-Update-Funktionalität zu haben. Aber wenn Sie in der Lage sein wollen, eine Ressource gleichzeitig zu manipulieren, müssen Sie einen URI für diese Ressource bereitstellen.
Und ja, es ist vollkommen in Ordnung, mehr als eine Möglichkeit zu haben, auf Ressourcen zuzugreifen. Du kannst es dir wie einen Blog vorstellen. Sie können Geschichten auf der Hauptseite oder auf Archivseiten erhalten oder indem Sie auf ihren Permalink gehen.
edit : Wenn Sie ein Massenupdate durchführen möchten, ohne auf das Problem zu stoßen, dass ein Client veraltete Daten an den Server sendet, haben Sie grundsätzlich zwei Möglichkeiten:
Diese haben jeweils Vorteile und Fallstricke. Das Problem mit dem Sperren ist, dass es zustandsbehaftet ist und daher nicht sehr gut in eine REST-Architektur passt. Wenn das Client-Programm abstürzt oder auf andere Weise stirbt, während es die Sperre hat, werden diese Daten dauerhaft gesperrt, es sei denn, Sie haben eine Art Sperrzeitlimit, was schwierig werden kann. Sperren kann auch zu einem Deadlock führen, wenn die Clients eine Art von ausgefallenen Transaktionen mit mehreren Sperren durchführen.
Das Problem bei optimistischer Parallelität ist, dass bei einer hohen Auslastung eines Datasets, bei der viele Clients es gleichzeitig ändern, viele, viele Versuche unternommen werden können, bevor ein bestimmter Client seine Daten veröffentlichen kann. Tatsächlich kann es passieren, dass ein langsamer Client durch die Veröffentlichung von Updates komplett abgeschnitten wird, weil andere Clients die Daten ständig ändern, was bedeutet, dass die langsamen Client-Änderungen immer fehlschlagen.
Sie müssen selbst entscheiden, welche dieser Optionen zu Ihnen passt. Diese Probleme treten auch auf, wenn Sie eine einzelne Ressource ändern (ein Update kann sich ändern), aber wenn Sie Ressourcen in einer Bulk-Oberfläche aggregieren, werden sie viel häufiger auftreten. Aus diesem Grund würde ich empfehlen, zwei Schnittstellen zu haben, wenn Sie Ressourcen aggregieren möchten. eine, in der auf die Ressourcen einzeln zugegriffen werden kann, und eine optionale Massenschnittstelle, auf der viele Ressourcen gleichzeitig gelesen und geschrieben werden können.