Nach dem Buch REST vs Too Many Requests

Aus Roy Fieldings Kommentar zu seinem eigenen Artikel, in dem gefälschte REST-Apis entschlüsselt werden :

Eine wirklich RESTful API sieht aus wie Hypertext. Jede adressierbare Informationseinheit trägt eine Adresse, entweder explizit (z. B. Link- und ID-Attribute) oder implizit (z. B. abgeleitet von der Medientypdefinition und Repräsentationsstruktur). Abfrageergebnisse werden durch eine Liste von Links mit zusammenfassenden Informationen dargestellt, nicht durch Arrays von Objektdarstellungen (die Abfrage ist kein Ersatz für die Identifizierung von Ressourcen).

Dies bedeutet, dass Sie, wenn Sie beispielsweise eine Liste der 100 zuletzt angemeldeten Benutzer abfragen und deren Namen und E-Mails anzeigen müssen, zunächst eine GETAbfrage nach der Ergebnisliste durchführen müssen, die (im Wesentlichen) eine Liste von Verknüpfungselementen sein, wobei jedes Verknüpfungsobjekt den URI einer Benutzerressource enthält. Sie müssten dann 100 weitere GET Anfragen stellen - eine für jede Benutzerressource -, bevor Sie tatsächlich über die Daten verfügen, die Sie zur Anzeige Ihrer Ergebnisse benötigen.

Das scheint unglaublich ineffizient. Gibt es wirklich keinen anderen wirklich REST-fähigen Weg, um die Daten zu erhalten, die Sie in 1 oder 2 Anfragen benötigen?

Gibt es wirklich keinen anderen wirklich REST-fähigen Weg, um die Daten zu erhalten, die Sie in 1 oder 2 Anfragen benötigen?

• Nicht wirklich
• Aber überleg es dir nicht

Wenn Sie an REST denken, denken Sie wie üblich daran, dass es eine Referenzimplementierung (das World Wide Web) gibt, gegen die Sie prüfen können.

Betrachten Sie das Amazon-Portal. Wenn ich dieses Lesezeichen mit einem leeren Cache öffne, stellt mein Browser Anforderungen an 275 Ressourcen.

Würde ich eine bessere Latenz erhalten, wenn der gesamte Status in einer einzigen Nutzlast abgerufen würde? Ja.

Würde es skalieren? würde es im Web skalieren? Wahrscheinlich nicht. Das sind 4,5 MB Daten, die nicht freigegeben werden können, da sie 1 KB enthalten, die für mein Profil spezifisch sind. Wenn meine Kollegin am Schreibtisch neben mir auch zu Amazon geht, zieht sie dieselben Daten über das Netzwerk.

Zerlegen Sie diese Nutzdaten in individuell adressierbare Ressourcen, und plötzlich wird es viel besser - wir erhalten jeweils noch 1 KB Personalisierung, und wir haben jeweils noch unsere lokal zwischengespeicherte Kopie der 4,5 MB, aber wir mussten das Netzwerk nicht knallen Dies ist schwierig, da die meisten unserer Anfragen von einem lokalen gemeinsam genutzten Cache bearbeitet wurden und nicht über das Internet weitergeleitet werden mussten.

Denken Sie auch daran, dass Sie nicht wirklich ein Problem mit mehreren Ressourcen haben , sondern ein Problem mit mehreren Anforderungen . Dies kann mithilfe von HTTP / 2.0-Push-Versprechungen verringert werden, indem der Server proaktiv Darstellungen pusht, die zwischengespeichert werden können. Vielleicht - ein zustandsloser Server weiß nicht, was der Client zwischengespeichert hat, und TLS schlägt vor, dass das Zwischenspeichern bei Zwischenprodukten keine Priorität hat ...

Dies bedeutet, dass Sie, wenn Sie beispielsweise eine Liste der 100 zuletzt angemeldeten Benutzer abfragen und deren Namen und E-Mails anzeigen müssen, zunächst eine GET-Abfrage für die Ergebnisliste durchführen müssen, was (im Wesentlichen) der Fall wäre ) eine Liste von Verknüpfungselementen sein, wobei jedes Verknüpfungsobjekt den URI einer Benutzerressource enthält. Sie müssten dann 100 weitere GET-Anforderungen stellen - eine für jede Benutzerressource -, bevor Sie tatsächlich über die Daten verfügen, die Sie zur Anzeige Ihrer Ergebnisse benötigen.

Wenn Sie dies in HTML tun würden, wäre Ihre Darstellung der zuletzt angemeldeten Benutzer wahrscheinlich ein Dokument mit einer Liste oder einer Tabelle mit Namen, E-Mail-Adressen und Links zu diesen Ressourcen. Ta-da.

Verlieren Sie diese Beobachtung durch Fielding nicht aus den Augen.

Das bedeutet nicht, dass ich denke, jeder sollte seine eigenen Systeme nach dem REST-Architekturstil entwerfen. REST ist für langlebige netzwerkbasierte Anwendungen gedacht, die mehrere Organisationen umfassen. Wenn Sie keine Notwendigkeit für die Einschränkungen sehen, verwenden Sie sie nicht.

BEARBEITEN

Kann ich das gleiche Argument für eine JSON-Darstellung vorbringen? Wenn die betreffende Ressource "100 zuletzt angemeldete Benutzer" ist und nicht das Ergebnis einer parametrisierten Abfrage, kann ich dann die Daten selbst anstelle von Ressourcenverknüpfungen zurückgeben? wenn nicht, warum? Warum unterscheidet sich JSON in dieser Hinsicht wesentlich von HTML?

Wie sie sich ähneln: Wenn Sie mehr Daten in die "Ergebnisliste" packen, sparen Sie die Kosten für zusätzliche Anforderungen und beeinträchtigen gleichzeitig die Skalierung. Der spezifische Medientyp, den Sie für die Darstellung verwenden, spielt keine Rolle - zumindest soweit ich weiß.

Wie sie sich unterscheiden: HTML ist ein Hypermedia-Format und JSON nicht - jede Standard-Client-Implementierung, die mit der HTML-Spezifikation vertraut ist, weiß, wie man die Links in einem HTML-Dokument findet, das Optionen wie das Vorabrufen unterstützt. JSON verfügt nicht über diese Standardisierung. Sie benötigen Out-of-Band-Informationen zur Datenstruktur, um zu verstehen, wo sich die Links in einer JSON-Darstellung befinden. HAL wäre in dieser Hinsicht eine engere Übereinstimmung mit HTML; Der Hauptunterschied zwischen HAL und HTML ist die Übernahme. HTML hat einen Vorsprung von 20 Jahren?

Für zusätzliche Einblicke können Sie auch das Atom-Syndication-Format überprüfen , das sowohl Einträge als auch Feeds (Listen von Einträgen) beschreibt, insbesondere die Regeln für atom: entry , auf die über eine eigenständige Ressource oder über eine Feed-Ressource zugegriffen werden kann.