Immaginate un'applicazione CRUD più complessa che abbia un'architettura a tre livelli e comunichi tramite i servizi web. Il client avvia una conversazione sul server e fa alcuni wizard come roba. Per elaborare la procedura guidata, il client ha bisogno del feedback fornito dal server.Webservices stateful vs. Stateless
Abbiamo iniziato una discussione sui webservice statici o stateless per questo approccio. Ho fatto delle ricerche combinate con la mia esperienza personale, che mi indirizza alla domanda menzionata in seguito.
webservices apolidi aventi le seguenti proprietà (nel nostro caso):
+ high scalability
+ high availability
+ high speed
+ rapid testing
- bloated contract
- implementing more logic on server-side
Ma possiamo attraversare i primi due punti, la nostra applicazione non necessita di elevata scalabilità e disponibilità.
Quindi arriviamo al servizio web stateful. Ho letto un sacco di blog e messaggi del forum e il punto più inventato l'attuazione di un webservice stateful era:
+ simplifies contract (protocol)
- bad testing
- runs counter to the basic architecture of http
Ma non lo fa quasi tutte le applicazioni Web avere questi punti negativi? Le applicazioni Web utilizzano i cookie, le stringhe di query, gli ID di sessione e tutto il resto per evitare l'apolidia di http.
Quindi, perché è così male per i servizi web?
Abbastanza vicino a un dupe: http://stackoverflow.com/questions/988819/stateful-webservice – gregmac
Mettere lo stato in un luogo che può facilmente gestire lo stato: il database –