Was ist der Vorteil der Verbundenheit?

Question

Was ist der Vorteil der Verbundenheit, wie definiert durch die Resource Oriented Architecture (ROA)?Die Art, wie ich es verstehe, ist der Kern der Verbundenheit ist die Fähigkeit zu kriechen, die gesamte Anwendung Zustand nur mit der root-URIs.

Aber wie sinnvoll ist das wirklich?

Zum Beispiel, stellen Sie sich vor, dass HTTP GET http://example.com/users/joe gibt einen link zu http://examples.com/uses/joe/bookmarks.

Es sei denn Sie schreiben eine dumme web-crawler (und auch ich Frage mich), müssen Sie dennoch zu dem client beibringen, was jeder link bedeutet, dass zur compile-Zeit.Das heißt, der client muss wissen, dass die "Lesezeichen " URI" gibt den URI-Lesezeichen für Ressourcen aus, und übergeben Sie die Steuerung über spezielle Lesezeichen-Behandlung-algorithmen.Sie können nicht nur passieren die links blind Allgemeine client-Methode.Da müssen Sie diese Logik sowieso:

1. Was ist der Unterschied zwischen dem Kunden herauszufinden, die URI zur Laufzeit versus bereitstellen, die er zur compile-Zeit (was http://example.com/users/bookmarks ein root-URI)?

2. Warum ist die Vernetzung mit http://example.com/users/joe/bookmarks/2 bevorzugt id="2"?

Der einzige Vorteil, den ich denken kann, ist die Fähigkeit, ändern Sie den Pfad des nicht-root-URIs im Laufe der Zeit, aber dies bricht zwischengespeichert links, so es ist nicht wirklich sinnvoll.Was vermisse ich?

Answer 1

Sie haben Recht, dass eine änderung Uris ist nicht wünschenswert, aber es kann passieren und mit vollständigen Uris statt zu konstruieren, Sie macht das wechseln einfacher zu handhaben.

Ein weiterer Vorteil ist, dass der client-Anwendung können schnell und einfach abgerufen werden Ressourcen von mehreren hosts.Wenn Sie erlaubt haben, Ihre Kunden zu bauen, die URI ist der client muss wissen, auf welchem host bestimmte Ressourcen befinden.Dies ist nicht eine große Sache, wenn alle Ressourcen auf einem host, aber es wird komplizierter, wenn Sie aggregieren von Daten aus mehreren hosts.

Mein letzter Gedanke ist, dass Sie vielleicht zu kurz gedacht, den Begriff der Verbundenheit, indem Sie betrachten es als eine statische Netzwerk-links.Sie sicher, dass der client muss wissen, über die mögliche Existenz von bestimmten Link auf eine Ressource, aber es muss nicht unbedingt genau wissen, was sind die Folgen von folgenden link.

Lassen Sie mich versuchen, ein ein Beispiel geben:Ein Benutzer ist eine Bestellung für einige Elemente und Sie sind bereit zu senden Ihr Warenkorb gelegt.Submit link kann tatsächlich gehen zwei verschiedenen Orten, abhängig davon, ob die Bestellung geliefert werden lokal oder International.Vielleicht Bestellungen über einem bestimmten Wert braucht, um durch zu gehen einen zusätzlichen Schritt.Der client einfach nur weiß, dass es Folgen die submit-link, aber es funktioniert nicht zusammengestellt haben, im wissen, wohin Sie gehen weiter.Sicher, Sie könnten der Aufbau eines gemeinsamen "Nächster Schritt", geben Sie der Ressource, so könnte der client haben, dieses wissen explizit, sondern durch den server liefern die Verknüpfung dynamisch, die Sie führen viel weniger client-server-Kopplung.

Ich denke, dass die links in Ressourcen als Platzhalter für das, was der Benutzer könnte wählen, zu tun.Wer wird die Arbeit tun, und wie es getan wird, ist bestimmt durch das, was uri, bringt der server auf diesen link.

Answer 2

Es ist einfacher zu erweitern, und Sie könnten kleine Anwendungen und Skripte schreiben, mit der Kernanwendung zu arbeiten zusammen ziemlich leicht.

Hinzugefügt: Nun, der ganze Punkt beginnt mit der Idee, dass Sie bei der Kompilierung-Zeit nicht angeben, wie URIs uids in einer fest codierten Mode zu konvertieren, stattdessen können Sie Wörterbücher oder Parsen verwenden, das zu tun, Sie viel mehr geben flexibles System.

Dann sagen später jemand anderes der URI-Syntax zu ändern entscheidet, könnte diese Person ein kleines Skript schreiben, die URIs übersetzt, ohne jemals Ihren Kern Anwendung zu berühren. Ein weiterer Vorteil ist, wenn Ihre URIs logische andere Benutzer sind, auch innerhalb eines Unternehmens Szenario kann leicht Mash-ups schreiben Nutzung des Systems zu machen, ohne die ursprüngliche App zu berühren oder sogar neu zu kompilieren es.

Natürlich ist die Gegenseite auf das ganze Argument ist, dass es länger dauern, wird ein URI-basiertes System über ein einfaches UID-System zu implementieren. Aber wenn Ihre App werden von anderen in einer regelmäßigen Art und Weise verwendet werden, dass die anfängliche Zeitaufwand wird erheblich Payback (könnte man sagen, eine gute Erweiterbarkeit auf Basis ROI haben).

Hinzugefügt: Und was ein weiterer Punkt ist ein mater von Geschmack zu einem gewissen Grad ist die URI selbst wird ein besserer Name sein, weil es eine logische vermittelt und definierte Bedeutung

Answer 3

Ich werde meine eigene Antwort hinzufügen:

1. Es ist viel einfacher server bereitgestellt URIs zu folgen, als sie selbst zu konstruieren. Dies gilt insbesondere, da Ressourcen Beziehungen zu komplex werden in einfachen Regeln ausgedrückt werden. Es ist einfacher, die Logik einmal auf dem Server als neu implementieren es in zahlreichen Kunden zu codieren.
2. Die Beziehung zwischen Ressourcen ändern, auch, wenn einzelne Ressource URIs unverändert bleiben. Zum Beispiel vorstellen, Indizes Google Maps ihre Kartenkacheln von 0 bis 100, von oben links nach unten rechts auf dem Bildschirm zu zählen. Wenn Google Maps die Skala ihrer Fliesen ändern waren, Clients, die relativ Kachel-Indizes berechnen würde brechen.
3. Benutzerdefinierte IDs identifiziert eine Ressource. URIs gehen noch einen Schritt weiter, indem die Identifizierung der Ressource, wie Darstellung abzurufen. Dies vereinfacht die Logik der Nur-Lese-Clients wie Web-Crawler oder Clients, die undurchsichtigen Ressourcen wie Video- oder Audio-Dateien herunterladen.