2016-05-26 6 views
3

Ich denke, ich verstehe das grundlegende Prinzip einer asynchronen POST-Methode von einem hohen Blickpunkt. Der große Vorteil ist, dass der Anrufer eine schnelle Antwort erhält, obwohl die Verarbeitung der Daten vom POST möglicherweise noch nicht abgeschlossen ist.Wie funktionieren asynchrone GET-Anfragen?

Aber ich verstehe nicht wirklich, wie dies für eine GET-Methode gilt. Die Antwort muss die Daten enthalten, also wie kann es eine Antwort geben, bevor die Verarbeitung abgeschlossen ist? Warum gibt es eine API mit einem GET-Request-Handler, der asynchrone Methoden verwendet?

Ich denke nicht, dass es für diese allgemeine Art von Frage von Bedeutung ist, aber ich schreibe in C# mit Web-API.

+0

Es wird der aktuelle Thread freigegeben, während E/A-Vorgänge asynchron ausgeführt werden. GET oder POST macht keinen Unterschied. In beiden Fällen fragen Sie nach etwas von einem Webserver und Sie erhalten eine Form der Antwort. Ob es eine Nutzlast hat oder nicht, ist irrelevant. – ManoDestra

+1

Sind Sie sicher, dass Sie wissen, was erwartet wird? Viele Leute denken, es beginnt etwas Arbeit an einem Hintergrund-Thread, der zu Verwirrung führt. – usr

Antwort

3

Im Netzwerk gibt es keinen asynchronen HTTP-Aufruf. Es sind nur Daten, die über TCP fließen. Der Server kann nicht feststellen, ob der Client intern oder asynchron synchronisiert ist.

der Anrufer bekommt eine schnelle Antwort

der Tat kann der Server die Antwortzeile und Header früh und Daten spät senden. Aber das hat nichts mit async IO oder einer asynchronen .NET Server Implementierung zu tun. Es sind nur ein paar Bytes, die früh und einige spät ankommen.

Es gibt also keinen Unterschied zwischen GET und POST hier.

Warum ... verwenden asynchrone Methoden?

Sie können Skalierbarkeit Vorteile für den Client und/oder den Server haben. Auf der HTTP-Ebene gibt es keinen Unterschied.

+0

Sicher, aber ein Server könnte (1) einen asynchronen Prozess starten, (2) Daten an den Client zurückgeben, (3) die Verbindung schließen und dann (4) die asynchrone Arbeit abschließen. Ich denke *, darum geht es dem OP. –

+1

@AaronBrager Ich denke jetzt, wir beide missverstanden. – usr

+0

Lassen Sie mich einige Verwirrung klären, wie ich denke, die Frage ist vage. Es gibt zwei Dinge, die mich dazu gebracht haben, diese Frage zu stellen. Eine davon ist die Verwendung von asynchronen Endpunkten im AccountController des Identity MVC-Beispielcodes. Ich weiß, dass die Leute, die diesen Code geschrieben haben, mehr wissen als ich, ich habe einfach nicht den Zweck erreicht, so viele Endpunkte asynchron zu machen. Der andere ist die Verwendung von EntityFramework ToListAsync in einem Endpunkt, wie ich in verschiedenen Beispielen gesehen habe. Aber wenn die Antwort gesendet werden kann, während die Daten abgerufen werden, ist es sinnvoller. –

1

So kann die App andere Dinge tun, die die Daten nicht benötigen.

Wenn Sie eine GET als synchrone Umsetzung (und lassen Sie uns sagen, dass Sie an einem schlechten Netzwerk, wo es 20 Sekunden dauert es zu bekommen), kann man nicht

  1. anzeigen Fortschritt
  2. dem Benutzer erlauben, abzubrechen
  3. Lassen sie sie andere initiieren GETs
  4. Lassen sie sie andere Teile der
  5. app

EDIT (siehe Kommentare): der Server wan ts antworten asynchron meistens aus dem gleichen Grund (um den Thread aufzugeben). Tatsächlich kann es sein, dass die Daten asynchron sind und einige Zeit brauchen - Sie möchten den Thread nicht für die gesamte Zeit blockieren.

+1

Es klingt, als ob du darüber sprichst, warum ein * Client * es asynchron tun würde. (Ihre Antwort ist großartig, wenn das die Frage ist.) Meine Interpretation war jedoch, dass das OP gefragt hat, warum der * Server * asynchron auf eine GET-Anfrage antworten würde. –

+1

Ich habe es jetzt dreimal gelesen und ich kann es nicht sagen. Ich nehme an, dass sie die Antwort wählen werden, die ihnen am sinnvollsten erscheint. –

+0

Ich wollte fragen, warum der SERVER asynchron antworten würde. Danke, dass Sie auf diese wichtige Unterscheidung hingewiesen haben. Ihre Antwort ist sehr sinnvoll für den Kunden. –

0

Es macht keinen Sinn, wenn Sie eine RESTful API erstellen, in der GET eine Ressource (oder eine Sammlung) zurückgeben und idempotent sein soll (keine Änderungen vornehmen).

Aber Wenn Sie diesen Prinzipien nicht folgen, könnte eine GET-Anfrage einige Arbeiten asynchron ausführen. Zum Beispiel GET /messages/3 könnte die Nachricht an den Client zurück, aber dann tun asynchron andere Arbeiten wie:

  • Marke als die Nachricht las
  • eine Push-Benachrichtigung an den anderen Clients des Benutzers senden, die anzeigt, dass die Nachricht
  • gelesen
  • planen einen Cronjob 30 Tage in der Zukunft
  • usw. die Nachricht

Keine von diesen eine RESTful API betrachtet würde zu löschen, werden aber nach wie vor von tim verwendet e zu Zeit.