Best practice für die Auswahl von verschachtelten Ressourcen in Rails?

Question

Welche Kriterien verwenden Sie, um zu entscheiden, ob Ressourcen verschachtelt werden sollen oder nicht?

In der Vergangenheit habe ich mich dafür entschieden, zu verschachteln, wenn die Indexaktion einer Ressource keinen Sinn ergibt, ohne auf eine zugehörige Ressource (den Elternteil) zuzugreifen.

Selbst während ich die oben genannten Kriterien schreibe, erkenne ich, dass sie bestenfalls mehrdeutig sind.

Ein Kollege hat gesagt:

Verschachteln Sie Ressourcen, weil dies das Verhältnis der zugehörigen Modelle in der URL-Struktur visuell abbildet ... Und es erleichtert die Änderung der URL, um zur Postansicht zurückzukehren. Wenn ich /posts/123/offers/555 sehe - weiß ich, dass ich zu /posts/123 gehen kann, um meinen Beitrag zu sehen. Wenn ich nur /offers/555 sehen würde, hätte ich keine Möglichkeit, zurück zum Beitrag zu gelangen, außer manuell durch die Website zu navigieren.

Für mich sollte die Manipulation der URL durch Benutzer keine Auswirkungen auf die Architektur der Anwendung haben und widerspricht dem, was ich als allgemein anerkanntes Prinzip verstehe, dass verschachtelte Ressourcen vermieden werden sollten, wenn möglich. Darüber hinaus würde dieses Argument dazu neigen, mehrstufige Verschachtelungen zu unterstützen, was wiederum so ziemlich jedem Artikel widerspricht, den ich gelesen habe.

Was sind Ihre Erfahrungen?

Answer 1

Ich verschachtel Routen, wie du es zuerst erwähnt hast, wenn die späteren Dinge in der Route ohne die früheren keinen Sinn ergeben. Kommentare auf einem Blog würden unter ressourcenartikel verschachtelt werden, weil ein Kommentar zu einem Artikel gehört, auch wenn du vielleicht einen individuellen Kommentar auf seiner eigenen Seite anzeigen möchtest (wer weiß warum...).

Dies hat auch Controller-Implementierungen. Wenn du den Artikel kennst, kannst du den spezifischen Kommentar zum Artikel finden. Das sorgt für effektivere Abfragen.

Außerdem hat dein Kollege recht, dass du mit Benutzern umgehen musst, die mit deinen Routen herumspielen, auch wenn er den falschen Grund genannt hat. Es geht nicht um ihre Bequemlichkeit, sondern um ihre Sicherheit.

Nehmen wir eine App wie Amazon mit Benutzern und Bestellungen. Wenn ich bei benutzer/5/bestellungen/2 bin, denke ich "hey! Ich kann einfach diese 5 in eine 4 ändern und dann die Bestellungen von jemand anderem sehen!" Wenn du Bestellungen nicht eingrenzt, wird die Logik auf Controller-Ebene zur Autorisierung eines Benutzers, bestellungen/2 anzusehen, viel komplizierter. Die Eingrenzung auf den Benutzer ermöglicht current_user.bestellungen.find(params[:id]) im Bestellungen-Controller. Der aktuelle Benutzer kann anhand der Authentifizierung gefunden werden, sodass sie nicht einfach IDs in der URL austauschen und jemand anderer werden können.