Представьте себе более сложное приложение 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
Но разве почти все веб-приложения имеют эти плохие точки? Веб-приложения используют куки файлы, строки запросов, идентификаторы сеансов и все прочее, чтобы избежать безгражданства http.
Так почему это плохо для веб-сервисов?
