ich würde mir garnicht die Frage stellen ob ein Webservice stateless oder stateful sein sollte (denn der ist per se stateless), sondern vielmehr ob für den genannten Use-Case die Verwendung eines Webservices sinnvoll ist.

Es gibt ja nicht umsonst Protokolle die stateful sind, vielleicht würde es sich lohnen, wenn sich die beiden darüber Gedanken machten.

Ciao,
Matthias

ich gebe Dir Recht: WebServices sollten stateless sein.

In deinem genannten Szenario wird wieder versucht durch “Kreativität” ein Symptom zu bekämpfen – nicht die Ursache! Nach meiner Meinung ein Klassiker in der Softwareentwicklung.

Wenn die Datenbank zu langsam ist: get it fixed!

Bleibt die Frage des Datendurchsatzes als Bottleneck zwischen den Parteien. Nicht alle Rechner sind an ein entsprechendes Datennetz angebunden und verfügen nur über eine geringe Bandbreite. Eine Abfrage, wie von Dir genannt, könnte somit für den Client tötlich sein. Eine Idee wäre es dem Aufrufer eine Methode zur Verfügung zu stellen in welcher lediglich die Anzahl der Treffermenge ( ggfl. auch die kummulierte Datenmenge ) erhält. z.B. Resultsetcount=1000 Resultsetsize=1MB.
Somit könnte der Client entsprechend reagieren und dem Benutzer die Wahl stellen ob dieser eine längere Wartezeit in anspruch nemhen möchte.

Ich bleibe dabei: WebServices sollten stateless sein! Sowie Datenbanken Datenbanken bleiben sollen etc.

Die Eierlegende-Woll-Milch-Sau gibt es in der Natur nicht und sie wird es in der Softwarewelt auch nie geben. Es ist das Gesamtsystem welches miteinander harmonieren muss, sonst wird es nicht funktionieren.

In diesem Sinne.

Gruß
Ed