In meiner Rails-App habe ich eine ziemlich standardmäßige has_many-Beziehung zwischen zwei Entitäten. A Foo hat null oder mehr Bars ; a Bar gehört zu genau einem Foo . Sowohl Foo als auch Bar werden durch einen einzigen Ganzzahl-ID-Wert identifiziert. Diese Werte sind in allen ihren Instanzen eindeutig.
Bar ist Existenz abhängig von Foo: es macht keinen Sinn, einen Bar ohne Foo zu haben.
Es gibt zwei Möglichkeiten, REST-Instanzen dieser Klassen zu referenzieren. Gegeben eine Foo.id von "100" und eine Bar.id von "200":
Beziehe jeden Foo und Bar über seine eigenen "Top-Level" URL-Routen wie folgt:
Referenzleiste als verschachtelte Ressource durch ihre Instanz von Foo:
Ich mag die verschachtelten Routen in # 2, da sie die tatsächliche Abhängigkeitsbeziehung zwischen den Entitäten genauer darstellt. Es scheint jedoch für sehr wenig Gewinn viel zusätzliche Arbeit zu bedeuten. Wenn ich davon ausgehe, dass ich über eine bestimmte Bar Bescheid weiß, muss mir nicht von einem bestimmten Foo erzählt werden; Ich kann das von der Bar selbst ableiten. In der Tat sollte ich wahrscheinlich das geroutete Foo überall bestätigen, wo ich hingehe (so dass du / foo / 150 / bar / 200 nicht tun könntest, vorausgesetzt, dass Bar 200 nicht Foo 150 zugewiesen ist). Letztendlich sehe ich nicht, was mir das bringt.
Gibt es also andere Argumente für oder gegen diese beiden Routing-Schemata?
Ich bin hauptsächlich besorgt über RESTful Updates / Shows / löscht bestimmte Bars. Um eine Liste von Bars für ein bestimmtes Foo zu erhalten (was normalerweise die "Index" -Aktion in Rails ist), ist es sinnvoll, eine verschachtelte Route wie / foo / 100 / bar zu haben. Die Seite auf dieser Route könnte genauso gut mit / bar / x wie mit / foo / 100 / bar / x verknüpft werden.
Sie suchen nach flachen Routen. Wie Sie bereits erwähnt haben, ist die Idee einer tief verschachtelten Route für Dinge wie Erstellen, Updates unnötig, da Sie den gewünschten Datensatz direkt anvisieren.
Ich habe das flache Routing-Ding noch nie gemacht, also gebe ich die Railscast-Episode weiter, wo Ryan Bates es wahrscheinlich besser erklärt als ich: 139 verschachtelte Ressourcen .
Bearbeiten: Sie können ein wenig mehr auf den Anleitungen für das Routing 3.8.4 .
Wie Sie bereits wissen, muss jeder Artikel eine eindeutige Adresse haben. Ich würde vorschlagen, dass je kürzer und einfacher die Adresse ist, desto besser für alle Beteiligten - Ihr Routing-Code, Ihre Client-Anwendungen usw. Wenn Sie eine Bar anhand ihrer eindeutigen ID identifizieren können, würde ich wahrscheinlich nur diese in der URL angeben / p>
Sie müssen die semantischen Informationen über die Zuordnung der Bar zu einem Foo jedoch nicht verlieren. Das kann Teil der Repräsentation sein.
Als Erweiterung können Sie dem Client erlauben, Bar 200 als / foo / 100 / bar / 200 zu adressieren, dann aber auf die bevorzugte / bar / 200 / Adresse umzuleiten, z. B. mit einer 303 ("Siehe Andere"). ) Antwort.
Die flache Verschachtelung von Rails gibt uns das Beste aus beiden Welten: Es lässt uns Foo-spezifisch machen Routen, bei denen es Sinn macht (Erstellen, Neu, Index) und Nur-Linien-Routen (Anzeigen, Bearbeiten, Aktualisieren, Zerstören).
Leider unterstützt das neue Routing DSL in Rails 3 (das ich verwende) nicht noch seichtes Routing (ab Beta 3). Es scheint, in den Werken aber Es ist nicht funktional für heute.
Sie können es jedoch fälschen, indem Sie die Ressource zweimal zuordnen, einmal verschachtelt und einmal flach:
%Vor%Dies wird mich überbrücken, bis die Option: shallow wieder aktiv ist.
Wenn jeder Balken von einem Foo abhängig ist, macht Option # 2 mehr Sinn. Wenn Foo beispielsweise ein Blog und Bar ein Post ist, ist es viel logischer, auf einen bestimmten Post bei example.bloghosting.com/blog/1/post/2 als example.bloghosting.com/post/21 zuzugreifen.
Tun Sie dies mit der neuesten Version von Rails:
%Vor%Dann im Router-Router (/config/routes.rb):
%Vor%Weitere Informationen finden Sie unter die Rails-API-Dokumentation .
Tags und Links ruby-on-rails nested resources rest routes