Leser, die neu in diesem Thema sind, werden von der endlosen Diskussion darüber, was Sie tun sollten , und dem relativen Fehlen von Lehren aus der Erfahrung beeindruckt sein. Die Tatsache, dass REST gegenüber SOAP "bevorzugt" wird, ist vermutlich ein Lernen auf hohem Niveau aus Erfahrung, aber meine Güte, wir müssen von dort aus Fortschritte gemacht haben? Es ist 2016. Roys Dissertation war im Jahr 2000. Was haben wir entwickelt? Hat es Spaß gemacht? War es einfach zu integrieren? Zu unterstützen? Wird es den Aufstieg von Smartphones und flockigen Mobilfunkverbindungen bewältigen?
Laut ME sind reale Netzwerke unzuverlässig. Fordert eine Zeitüberschreitung an. Verbindungen werden zurückgesetzt. Netzwerke fallen stunden- oder tagelang aus. Züge fahren mit mobilen Benutzern an Bord in Tunnel. Für jede gegebene Anfrage (wie gelegentlich in all diesen Diskussionen bestätigt) kann die Anfrage auf ihrem Weg ins Wasser fallen, oder die Antwort kann auf dem Rückweg ins Wasser fallen. Unter diesen Umständen war es für mich immer etwas brutal und naiv, PUT-, POST- und DELETE-Anfragen direkt gegen materielle Ressourcen zu stellen.
HTTP unternimmt nichts, um einen zuverlässigen Abschluss der Anforderungsantwort sicherzustellen, und das ist in Ordnung, da dies die Aufgabe netzwerkfähiger Anwendungen ist. Wenn Sie eine solche Anwendung entwickeln, können Sie durch die Rahmen springen, um PUT anstelle von POST zu verwenden, und dann durch weitere Rahmen, um eine bestimmte Art von Fehler auf dem Server zu melden, wenn Sie doppelte Anforderungen erkennen. Zurück auf dem Client müssen Sie dann durch die Rahmen springen, um diese Fehler zu interpretieren, erneut abzurufen, erneut zu validieren und erneut zu veröffentlichen.
Oder Sie können dies tun : Betrachten Sie Ihre unsicheren Anforderungen als kurzlebige Einzelbenutzerressourcen (nennen wir sie Aktionen). Clients fordern eine neue "Aktion" für eine inhaltliche Ressource mit einem leeren POST an die Ressource an. POST wird nur dafür verwendet. Sobald der Client sicher im Besitz des URI der frisch geprägten Aktion ist, sendet er die unsichere Anforderung an den Aktions-URI und nicht an die Zielressource . Das Auflösen der Aktion und das Aktualisieren der "echten" Ressource ist ordnungsgemäß Aufgabe Ihrer API und hier vom unzuverlässigen Netzwerk entkoppelt.
Der Server erledigt das Geschäft, gibt die Antwort zurück und speichert sie anhand des vereinbarten Aktions-URI . Wenn etwas schief geht, wiederholt der Client die Anforderung (natürliches Verhalten!), Und wenn der Server sie bereits gesehen hat, wiederholt er die gespeicherte Antwort und unternimmt nichts anderes .
Sie werden die Ähnlichkeit mit Versprechungen schnell erkennen: Wir erstellen den Platzhalter für das Ergebnis und geben ihn zurück, bevor wir etwas unternehmen. Ebenso wie ein Versprechen kann eine Aktion einmal erfolgreich sein oder fehlschlagen, aber das Ergebnis kann wiederholt abgerufen werden.
Das Beste ist, dass wir sendenden und empfangenden Anwendungen die Möglichkeit geben, die eindeutig identifizierte Aktion mit der Eindeutigkeit in ihrer jeweiligen Umgebung zu verknüpfen. Und wir können anfangen, verantwortungsbewusstes Verhalten von Kunden zu fordern und durchzusetzen: Wiederholen Sie Ihre Anfragen so oft Sie möchten, aber generieren Sie keine neue Aktion, bis Sie über ein endgültiges Ergebnis der vorhandenen verfügen.
Als solche verschwinden zahlreiche heikle Probleme. Wiederholte Einfügeanforderungen erzeugen keine Duplikate, und wir erstellen die eigentliche Ressource erst, wenn wir im Besitz der Daten sind. (Datenbankspalten können nicht nullwertfähig bleiben). Wiederholte Aktualisierungsanforderungen treffen nicht auf inkompatible Zustände und überschreiben nachfolgende Änderungen nicht. Clients können die ursprüngliche Bestätigung aus irgendeinem Grund (erneut) abrufen und nahtlos verarbeiten (Client stürzte ab, Antwort ging verloren usw.).
Aufeinanderfolgende Löschanforderungen können die ursprüngliche Bestätigung anzeigen und verarbeiten, ohne dass ein 404-Fehler auftritt. Wenn die Dinge länger dauern als erwartet, können wir vorläufig reagieren und haben einen Ort, an dem der Kunde das endgültige Ergebnis überprüfen kann. Der schönste Teil dieses Musters ist seine Kung-Fu (Panda) -Eigenschaft. Wir nehmen eine Schwäche, die Neigung der Kunden, eine Anfrage zu wiederholen, wenn sie die Antwort nicht verstehen, und verwandeln sie in eine Stärke :-)
Bevor Sie mir sagen, dass dies nicht RESTful ist, bedenken Sie bitte die zahlreichen Möglichkeiten, wie REST-Prinzipien respektiert werden. Clients erstellen keine URLs. Die API bleibt erkennbar, wenn auch mit einer kleinen Änderung in der Semantik. HTTP-Verben werden entsprechend verwendet. Wenn Sie der Meinung sind, dass dies eine große Änderung ist, kann ich Ihnen aus Erfahrung sagen, dass dies nicht der Fall ist.
Wenn Sie der Meinung sind, dass Sie große Datenmengen speichern müssen, sprechen wir über das Volumen: Eine typische Aktualisierungsbestätigung ist ein Bruchteil eines Kilobytes. HTTP gibt Ihnen derzeit ein oder zwei Minuten Zeit, um endgültig zu antworten. Selbst wenn Sie Aktionen nur eine Woche lang speichern, haben Kunden reichlich Gelegenheit, sich zu informieren. Wenn Sie sehr große Volumes haben, möchten Sie möglicherweise einen dedizierten säurekonformen Schlüsselwertspeicher oder eine In-Memory-Lösung.
