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