RESTful APIs müssen stateless sein, aber was ist Parallelität?

Ich bin gespannt, wie ich das Problem lösen das concurrency-Problem für eine RESTful API. Genauer gesagt, habe ich eine Sammlung von Objekten, die manuelle Prüfung und Aktualisierung, z.B. Anzahl der Zeilen, die eine Spalte aktualisiert wird, von der hand; allerdings, wenn ich öffnen Sie die API, um eine Reihe von Kunden, Sie alle greifen diese Elemente von oben nach unten, so dass viele Benutzer in der Füllung der Spalte der gleichen Zeile zur gleichen Zeit. Ich würde es vorziehen, nicht zu Kollisionen, und die einfache, stateful Weg ist, um nur dump die Elemente in einer Warteschlange auf der service-und pop Sie aus, wie Menschen Sie beantragen.

Was ist der stateless-Variante von dem hier? Hash der IP-Adresse oder zufällig greifen die Zeilen basierend auf id?

:: update ::

"Hrm, also muss es einfach sein, Staatenlose, aus der Perspektive des Kunden?

Dass macht sicherlich sehr viel Sinn. Ich war gerade das Lesen eines Artikels (ibm.com/developerworks/webservices/library/ws-restful) über RESTful APIs, und nach der Begegnung die etwas über paging, ich war besorgt, dass meine ganz stateful Warteschlange war ähnlich wie das Inkrementieren von einer Seite, doch eigentlich sind Sie ganz anders als "nächste Seite" ist relativ-auf der client-Seite, in der Erwägung, dass "pop" ist immer zustandslos für den Kunden: Es ist egal, was war, knallte vor.

Dank für das clearing meinem Kopf!" -Mir

  • Sehe ich nicht wirklich das problem/die Frage hier. RESTful APIs werden kann - und IME-fast immer sind - unterstützt durch stateful-Server. Könnten Sie das klären, das problem, das Sie versuchen zu lösen?
  • e-tags können verwendet werden, bieten Parallelität
  • Hrm, also muss es einfach sein, Staatenlose, aus der Perspektive des Kunden? Das macht sicherlich sehr viel Sinn. Ich war gerade das Lesen eines Artikels (ibm.com/developerworks/webservices/library/ws-restful) über RESTful APIs, und nach der Begegnung die etwas über paging, ich war besorgt, dass meine ganz stateful Warteschlange war ähnlich wie das Inkrementieren von einer Seite, doch eigentlich sind Sie ganz anders als "nächste Seite" ist relativ-auf der client-Seite, in der Erwägung, dass "pop" ist immer zustandslos für den client. Es ist egal, was war, knallte vor. Dank für das clearing meinem Kopf!
InformationsquelleAutor M. Herold | 2012-03-23
  1. 5

    Gibt es zwei grundlegende Ansätze, die Sie ergreifen können:

    1. Gehen komplett staatenlos, und erlässt einen "letzten Wunsch gewinnt" - Strategie. So seltsam es auch klingen mag, es ist wahrscheinlich, die sauberste Lösung in Bezug auf die Vorhersehbarkeit, die Skalierbarkeit, die Komplexität des Codes und die Implementierung auf client-und server-Seiten. Es gibt auch eine Menge der Rangfolge für Sie: schauen Sie, wie Websites wie Google paginieren, die durch Abfragen mit Hilfe von start=10 für Seite 2, start=20 für Seite 3, etc.

      Finden Sie möglicherweise, die änderungen der Inhalte in Seiten, wie Sie navigieren Sie zwischen Ihnen hin und her, aber so was? Sie immer die neuesten Informationen, und Google kann mit Ihren Anforderungen auf einer Ihrer vielen Servern zimmerreserviereung, ohne das Sie finden Ihre session-Informationen, um zu bestimmen, was Ihre letzten Abfrage Kontext war.

      Der größte Vorteil dieses Ansatzes ist die Einfachheit Ihrer server-Implementierung. Jede Anfrage kann nur passieren rechts durch, um die Daten-Schicht an der Rückseite, und es ist absolut reif für das caching auf HTTP-Ebene (per E-Tags oder Last-Modified-Header) und der server-Seite (mit so etwas wie memcache, zum Beispiel).

    2. Gehen stateful, und herauszufinden, einen Weg, um Ihre Server dole out irgendeine Art von pro-client sperren, oder token für jeden API - "Sitzung". Dieser wird wie die versuchen gegen die ocean ' s tide mit einem Stock, weil Sie werden am Ende scheitern und frustriert.

      Wie werden Sie identifizieren Kunden? Session-keys? Die IP-Adresse? Datei-Deskriptor für den socket Ritten Sie in auf (viel Glück mit, dass, wenn Sie mit einem transport wie HTTP, wo kann die Verbindung geschlossen werden zwischen den Anfragen...)? Die details, die Sie für dieses haben, beibehalten werden auf der server-Seite, oder du wirst einige böse alte sticky-session-Funktion auf dem app-server (und wenn ja, Himmel hilf deinen Kunden, wenn der server mit down geht mid-session).

      Wie werden Sie behandeln API-clients, verschwinden abrupt ab? Wird Sie timeout Ihre session-locks automatisch durch ein reaper-thread Aufräumen im Leerlauf sein? Das ist mehr code, mehr Komplexität und mehr Plätze für Fehler zu verstecken. Was über die API-clients, die kommen zurück von einer langen Zeit im Leerlauf und versuchen, Sie zu re-verwenden Sie eine abgelaufene Sperre, wie soll die client-Anwendungen aufgebaut werden, um diese situation meistern?

    Ich könnte weitermachen, aber ich hoffe, Sie sehen mein Punkt. Gehen Sie mit der option 1, und gehen Sie staatenlos. Sonst wirst du am Ende versuchen, die Spur client-Zustand auf der server-Seite. Und die einzige Sache, sollte track ein client der client selbst.

    • Ich glaube nicht, dass die Annahme sich der Inhalt ändert, während das surfen ResultSet Seiten ist der eine und einzige Weg zu denken. Sie sehen möglicherweise doppelte Einträge -- OK (und client behandeln konnte, diese ohnehin), aber Sie kann auch verpasst Einträge völlig durch Umzüge im Rahmen der letzten / vorherigen Seiten -- nicht schön. Für die Google-Suche Ergebnisse, die möglicherweise nicht die Materie, sondern auch in anderen Kontexten kann es.
    • Als alternative kann man fetch "alle IDs" auf dem client (OK, für die google-Suchergebnisse, das ist nicht machbar, die meisten der Zeit) und gehen Sie diese Liste durch, Seite um Seite, laden Sie weitere Inhalte, wenn du das ResultSet Seite mit dieser ID sub-set. Die schlechten Nachrichten sind, dass das problem zurück kommt um die Ecke: Es können auch Elemente, die mittlerweile gelöscht (die kann nicht mehr geladen werden, es muss irgendwie abgefangen), und es können neue Elemente Hinzugefügt, währenddessen die Sie nicht sehen, dass durchsuchen Ihrer aktuellen ResultSet. Also die Frage ist: Was ist für Sie wichtiger?
    • Wenn Sie kümmern sich nicht über fehlende oder doppelte Objekte beim Browsen der Ergebnismenge seitenweise hin und her, dann werden Sie in Ordnung sein mit dem setzen der Seitenzahl oder der index range in der URL als parameter -- zu Lasten des service mit laden und schmeißt alle Gegenstände, die gestellt worden wären, die auf jeder Seite vor. (Wie geht Google damit um? Jemand versucht, eine absurde Abfrage und zunächst die Angabe einer hohen Seitenzahl, wie "query=Millionär&page=59786"?)
    • Wenn auf der anderen Seite wollen Sie stabile Ergebnis-sets bei Seite surfen, während gleichzeitig frisches detail-Daten-cache zumindest das Ergebnis der Abfrage ID-Satz (wenn möglich) und zu Fuß durch dieses set beim surfen auf den Seiten. Sie wird zu tun haben mit inzwischen entfernt Elemente, die jedoch, und Sie nicht sehen können Elemente Hinzugefügt vor erreichen der Seite, wo Sie "erschienen wäre, wenn die Abfrage wurden gebeten, später". -- Es gibt einige Preis zu zahlen, wie auch immer, wie es scheint.
    • Durch die Art und Weise dieser Ansatz dürfte erheblich sein, wie "Erholsam" auch da ist kein Staat verwaltet der server-Seite. Wenn man die item-IDs als äquivalent zu den hyperlinks, die auf eine single-item-Ressourcen-Lage, dann ist es hypermedia-Stil auch (und wäre perfekt also, wenn die ID gesetzt ist in der Tat eine ID resource locator setzen, dann aber mehr Bandbreite und client-side-Speicher wird benötigt).
    InformationsquelleAutor Brian Kelly
  2. 1

    Es ist in Ordnung zu halten-resource-state. Die "stateless Verbot" bezieht sich gerade auf Sitzungsstatus.

    Hier ein Auszug aus Roy Fielding ' s seminal REST Ableitung:

    Wir als Nächstes fügen Sie eine Einschränkung der client-server-Interaktion:
    Kommunikation muss Staatenlosen in der Natur, wie in der
    client-stateless-server (CSS) - Stil Abschnitt 3.4.3 (Abbildung 5-3),
    so dass jede Anfrage vom client an den server muss alle der
    Informationen notwendig, die Anforderung zu verstehen, und nicht nehmen
    Vorteil, alle gespeicherten Kontext auf dem server. Sitzungszustand ist
    daher gehalten, die vollständig auf dem client.

    InformationsquelleAutor Raymond Hettinger
Schreibe einen Kommentar