Представьте себе более сложное приложение CRUD, которое имеет трехуровневую архитектуру и взаимодействует через веб-сервисы. Клиент начинает разговор с сервером и делает что-то вроде мастера. Для обработки мастера клиенту нужна обратная связь с сервером.

Мы начали обсуждение веб-сервисов с отслеживанием состояния или без сохранения состояния для этого подхода. Я провел некоторое исследование в сочетании с собственным опытом, который указывает на вопрос, упомянутый ниже.

Веб-сервисы без сохранения состояния, имеющие следующие свойства (в нашем случае):

+ high scalability
+ high availability
+ high speed
+ rapid testing
- bloated contract
- implementing more logic on server-side

Но мы можем вычеркнуть первые два пункта, наше приложение не нуждается в высокой масштабируемости и доступности.

Итак, мы приходим к веб-сервису с отслеживанием состояния. Я прочитал кучу блогов и сообщений на форуме, и наиболее изобретенным моментом реализации веб-сервиса с состоянием было:

+ simplifies contract (protocol)
- bad testing
- runs counter to the basic architecture of http 

Но разве почти все веб-приложения не имеют этих плохих моментов? Веб-приложения используют файлы cookie, строки запросов, идентификаторы сеансов и все прочее, чтобы избежать сохранения состояния http.

Так почему же это плохо для веб-сервисов?