RESTful Web-Anfragen und Tracking-Webseiten für Nutzeraktivitäten

8

Jemand hat mir diese Frage vor ein paar Tagen gestellt und ich hatte keine Antwort:

  

Da HTTP ein zustandsloses Protokoll ist. Wenn wir www.google.com öffnen, können Sie es tun   ein REST-Aufruf genannt werden?

Was ich denke:

Wenn wir auf google.com suchen, werden alle Informationen über Cookie- und URL-Parameter übermittelt. Es sieht aus wie eine staatenlose Anfrage. Die Suchergebnisse sind jedoch nicht unabhängig von der vergangenen Anfrage des Benutzers. Die Suchergebnisse sind spezifisch für das Nutzerinteresse und -verhalten. Jetzt sieht es nicht wie eine staatenlose Anfrage aus.

Ich weiß, das ist eine alte Frage und ich habe viele SO-Antworten gelesen, wie Warum ist HTTP ein zustandsloses Protokoll? , aber ich bin immer noch nicht in der Lage zu verstehen, was passiert, wenn Benutzeraktivitäten wie bei Google oder Amazon (Empfehlungen basierend auf vergangenen Einkäufen) oder anderen auf Benutzeraktivitäten basierenden Empfehlungswebsites verfolgt werden / p>

Ist es RESTful oder ist es RESTless?

Was ist, wenn ich eine Web-App erstellen möchte, in der ich die REST-Architektur verwende und trotzdem benutzerspezifische Antworten bereitstelle?

    
Amit Tripathi 08.11.2016, 05:12
quelle

3 Antworten

7

HTTP ist zustandslos, der Google Application Layer jedoch nicht. Die spezifischen Cookies und ihre Bedeutung sind Teil der Anwendungsschicht.

Betrachten Sie dasselbe mit TCP / IP. IP ist ein zustandsloses Protokoll, TCP jedoch nicht. Die Existenz von Status in TCP eingebettet in IP-Pakete bedeutet nicht, dass das IP-Protokoll selbst einen Zustand hat.

Macht das also einen REST-Anruf? Nein.

Obwohl HTTP zustandslos ist & amp; Ich würde vermuten, dass www.google.com, wenn mit Cookies deaktiviert, die Ergebnisse für jede Anfrage identisch wären, so dass es fast zustandslos ist (Google verfolgt wahrscheinlich immer noch IP, um die Häufigkeit der Anfragen zu begrenzen).

Aber die Anwendungsschicht ist nicht zustandslos. Eines der Prinzipien von REST besteht darin, dass das System zwischen den Anforderungen keine Statusdaten über den Client speichert, um die Antworten zu modifizieren. Im Falle von Google passiert das eindeutig nicht.

    
Steve E. 16.11.2016, 04:52
quelle
3

Sie sollten wahrscheinlich von Fieldings Kommentaren zu Cookies in seiner Abschlussarbeit ausgehen , und überprüfen Sie dann Fieldings weitere Gedanken, die auf rest-discuss veröffentlicht wurden. p>

Meine Interpretation von Fieldings Gedanken, angewandt auf diese Frage: Nein, es ist nicht REST. Die Suchergebnisse ändern sich abhängig vom Status des Cookie-Headers in der Anfrage, dh die Darstellung der Ressource ändert sich abhängig vom Cookie, dh dass ein Teil der Ressourcen-ID im Cookie-Header erfasst wird.

  

Die meisten Probleme mit Cookies sind auf das Brechen der Sichtbarkeit zurückzuführen,   Auswirkungen auf das Caching und die Hypertext-Anwendungs-Engine - Fielding, 2003

Caching scheint für Google keine große Priorität zu haben. Die zurückgegebene Repräsentation enthält einen privaten Cache-Control-Header, der die Teilnahme an Zwischenkomponenten einschränkt.

    
VoiceOfUnreason 08.11.2016 06:33
quelle
3

Es scheint, dass die Bedeutung von "staatenlos" (hypothetisch) über seinen praktischen Ausdruck hinausgeht.

Betrachten Sie ein Web-System ohne DB. Sie rufen eine (RESTful) API auf, Sie erhalten immer genau die gleichen Ergebnisse. Das ist vollkommen staatenlos ... Aber das ist auch kein richtiges System.

Ein echtes System, in praktisch jeder Implementierung, enthält Daten. Darüber hinaus sind diese Daten die "Ressourcen", auf die RESTful API zugreifen können. Natürlich ändern sich auch Daten aufgrund von API-Aufrufen. Wenn Sie also den Wert einer Ressource erhalten, ihren Wert ändern und dann ihren Wert erneut erhalten, erhalten Sie einen anderen Wert als beim ersten Lesen. Dies bedeutet jedoch nicht, dass die Reads selbst nicht staatenlos waren. Sie sind staatenlos in dem Sinne, dass sie für jeden Aufruf die gleiche Aktion (oder genauer: Ressource) darstellen. Änderungen müssen manuell vorgenommen werden, indem eine andere RESTful-API verwendet wird, um den Ressourcenwert zu ändern, der dann im nächsten Aufruf widergespiegelt wird.

Was aber ist der Fall, wenn wir eine Ressource haben, die sich ohne ein manuelles, standardmäßiges API-Verb ändert? Angenommen, wir haben eine Ressource, die zählt, wie oft auf eine andere Ressource zugegriffen wurde. Oder eine andere Ressource, die aus anderen Daten Dritter stammt. Natürlich ist dies immer noch ein staatenloses Protokoll.

Darüber hinaus reagiert fast jedes System - z. B. jedes System, das einen Authentifizierungsmechanismus enthält - auf unterschiedliche Weise für die gleichen API-Aufrufe, z. B. abhängig von den Benutzerprivilegien. Und dennoch ist es REST-gestützten Systemen natürlich nicht verboten, ihre Benutzer zu authentifizieren ...

Kurz gesagt sind zustandslose Systeme für dieses Protokoll zustandslos. Wenn Google die Anrufe verfolgt, so dass, wenn ich dieselbe Ressource in derselben Sitzung anrufe , ich verschiedene Antworten bekomme, dann bricht es die stateless-Anforderung. Aber solange die zurückgegebene Antwort aufgrund von Daten auf Anwendungsebene unterschiedlich ist und nicht sessionbezogen ist, ist diese Anforderung nicht gebrochen.

AFAIK, was Google tut, hängt nicht unbedingt mit Sitzungen zusammen. Wenn derselbe Benutzer dieselbe Suche unter völlig identischen Bedingungen (z. B. IP, geographischer Ort, Betriebssystem, Browser usw.) durchführt, erhalten sie die gleiche Antwort. Wenn eine neue identische Suche aufgrund von dem, was Google beim letzten Anruf "gelernt" hat, zu anderen Ergebnissen führt, ist es immer noch zustandslos, weil - wiederum - dieser zweite Anruf das gleiche Ergebnis erzeugt hätte, wenn es in einer anderen Sitzung durchgeführt worden wäre aber unter identischen Bedingungen.

    
Mike 16.11.2016 11:18
quelle

Tags und Links