Wann sollten Unterelemente in die RESTful-Ressourcendarstellung eingefügt werden?

Question

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 auszuarbeiten, berücksichtigen Sie Folgendes: Firma kann mehrere Mitarbeiter haben. Normalerweise würde diese Situation wahrscheinlich als zwei getrennte Ressourcen, Firma und Mitarbeiter, gestaltet sein, wobei der Angestellte die Unterressource der Firma wäre.

/company/acme/ 
/company/acme/employees/ 
/company/acme/employee/john 

Mit diesem URI-Design, sollten Unternehmen Vertretung Links zu ihren Mitarbeitern zählen, aber die XML-Darstellung würde wahrscheinlich nicht emplyoyees per se.

Daher, wenn es Sinn macht, Sub-Elemente durch die Eltern? Und gibt es eine Situation, in der es sinnvoll wäre, die Unterposition nur über ihre Eltern darzustellen. Ich meine, dass es überhaupt keine URI für Sub-Items geben würde. Sie konnten nur durch die Elternressource erreicht werden.

<company> 
<name>Acme</name> 
<employees> 
    <employee>John</employee> 
    <employee>Jack</employee> 
</employees> 
</company> 

Ist es sinnvoll, nur eine Methode bieten auf eine Ressource zuzugreifen: wenn ein Elternteil seine Unterelemente legt, kann es eine explizite URI sein für die Unterpunkte zu? Also, wenn das XML des Unternehmens die Mitarbeiter des Unternehmens enthält, würde es Sinn machen,/company/acme/employees URI anzubieten, obwohl Sie die gleichen Informationen über die Unternehmensressourcen erhalten können?

Answer 1

Wenn die Unterressource nur im Zusammenhang mit dem übergeordneten Element sinnvoll ist, dann sollte yes innerhalb des übergeordneten Elements zurückgegeben werden. Zum Beispiel macht ein <li> Element in HTML als Unterressource keinen Sinn.

Wenn eine Ressource jedoch eigenständig sein kann und Sie eine Ressource unabhängig von anderen Ressourcen bearbeiten möchten, sollte sie ihren 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üssten, 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 Massenabfrageschnittstelle zu haben, mit der 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. Wenn Sie jedoch nur eine Ressource gleichzeitig bearbeiten möchten, müssen Sie einen URI für diese Ressource bereitstellen.

Und ja, es ist vollkommen in Ordnung, mehr als eine Möglichkeit, 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.

bearbeitet: Wenn Sie zu einem Bulk-Update mögen, ohne in das Problem läuft auf den Server einen Client gibt veraltete Daten zu haben, Sie haben grundsätzlich zwei Möglichkeiten:

1. Locking.Ein Client teilt dem Server mit: "Ich möchte eine Sperre für diesen gesamten Datensatz", ruft die Daten ab, die er ändern möchte, ändert die Daten, sendet sie zurück an den Server und entsperrt sie.
2. Optimistic concurrency: Der Client lädt die Datenmenge herunter, die mit einer Art Revisionstag markiert ist, den der Server jedes Mal ändert, wenn er neue Daten erhält. Der Client ändert es und sendet es zurück an den Server. Wenn eine der anderen Daten in der Gruppe in der Zwischenzeit geändert wurde, enthält das Revisions-Tag keine Daten mehr und der Server antwortet mit einem "Entschuldigung, Ihre Daten sind veraltet, versuchen Sie es erneut."

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 Sperrzeitüberschreitung, die schwierig werden kann. Das Sperren kann auch zu einem Deadlock führen, wenn die Clients eine Art von ausgefallenen Transaktionen ausführen, die mehrere Sperren umfassen.

Das Problem mit optimistischer Parallelität ist, dass bei einer hohen Belastung eines Datensatzes, bei der viele Clients gleichzeitig ändern, viele, viele Versuche erforderlich sind, bevor ein bestimmter Client seine Daten veröffentlichen kann. In der Tat kann ein langsamer Client von der Veröffentlichung von Updates vollständig abgeschnitten werden, da andere Clients die Daten kontinuierlich so ändern, 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.