title: Stateful vs. Stateless Webservices
body: <p>Imagine a more complex CRUD application which has a three-tier-architecture and communicates over webservices. The client starts a conversation to the server and doing some wizard like stuff. To process the wizard the client needs feedback given by the server.</p>
  
  <hr>
  
  <p>We started a discussion about stateful or stateless webservices for this approach. I made some research combined with my own experience, which points me to the question mentioned later.</p>
  
  <p>Stateless webservices having the following properties (in our case):</p>
  
  <pre><code>+ high scalability
  + high availability
  + high speed
  + rapid testing
  - bloated contract
  - implementing more logic on server-side
  </code></pre>
  
  <p>But we can cross out the first two points, our application doesn't needs high scalability and availability.</p>
  
  <p>So we come to the stateful webservice. I've read a bunch of blogs and forum posts and the most invented point implementing a stateful webservice was:</p>
  
  <pre><code>+ simplifies contract (protocol)
  - bad testing
  - runs counter to the basic architecture of http 
  </code></pre>
  
  <p>But doesn't almost all web applications have these bad points? Web applications uses cookies, query strings, session ids, and all the stuff to avoid the statelessness of http.</p>
  
  <p>So why is it that bad for webservices?</p>