Представьте себе более сложное приложение 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.
Так почему же это плохо для веб-сервисов?