Я превращаюсь из настольного разработчика в веб-разработчика, и у меня возникают проблемы с пониманием того, почему HTTP не сохраняет состояния. Каковы причины этого? Каким образом такой разработчик настольных систем, как я, может перейти в среду разработки без сохранения состояния?
15
Ответы:
Это лучшее объяснение интернета без гражданства, которое я видел:
Как я объяснил REST моей жене
http://www.looah.com/source/view/2284
источник
Как, по-вашему, можно было бы хранить состояние миллиардов миллиардов миллиардов миллиардов соединений? :) Таким образом, вы сохраняете состояние только там, где это необходимо, в сессиях.
Кстати: HTTP не без соединения.
источник
persistent connections
так называемый keep-alive. Я не эксперт по сети, но у вас есть реальное соединение по HTTP в большинстве случаев :)Как разработчик настольных систем, вам может быть удобнее использовать богатый пользовательский интерфейс. Переход в Интернет может показаться шагом назад. В веб-мире свободы творчества меньше, и это может дать вам чувство стеснения. Не позволяйте этому сбить вас с толку! Существует ряд вещей, которые могут помочь вам осуществить переход, и вот их краткий список:
Удачного программирования!
источник
Потому что было время, когда не было миллионов и миллионов веб-страниц. Потому что было время, когда только в университетах и исследовательских центрах было несколько страниц. Было время, когда не было широкополосного доступа, и http был передан через 1200 бод-модемов, установленных на настольных телефонах. Было время, когда «богатым веб-приложениям» требовалась, по их мнению, нелепая полоса пропускания. И помните, TCP / IP был создан, потому что ранний интернет был очень ненадежным.
HTTP 1.0 был в начале 1990-х годов. Подумайте о том, каким был Интернет тогда, и почему они разработали его так, как они это сделали.
источник
Все вроде развивалось. Интернет существовал до появления веб-браузеров и Интернета. Это был кипящий горшок с ftp, телнетом, сусликом, пингом, пальцем и несколькими другими битами и бобами. Первый веб-браузер, Mosaic (я думаю, это было очень давно, 1991, я думаю, я учился в колледже), действовал как своего рода путаница между ftp и средством просмотра документов. Волшебство произошло в том, что у вас могли быть ссылки в документе, которые открывали бы новый документ.
Вся интерактивность, которую мы сейчас развили в течение следующих 20 лет. Это была не счастливая эволюция. У нас были войны браузеров, IE и Netscape решили использовать его для контроля над стандартами (упрощение;)), и различные другие третьи стороны начали внедрять плагины для обеспечения насыщенного контента. Ява собиралась стать волшебной пулей и, конечно, Flash. Кто-нибудь помнит плагины VRML, которые обещали 3d-миры и поставили ровно полдюжины 3d-моделей моделей Star Wars?
Я немного увлекся к концу, но вы поняли идею :)
источник
Основные причины связаны с сочетанием того, что, по мнению ацетемии, было целью HTTP, и соображениями масштабируемости. Первоначально HTML был разработан для обмена информацией или тезисами за пределами академических границ. Это был чисто стилизованный текст. Только когда первый браузер позволил вам показывать картинки, люди начали думать за пределами этой модели.
Следующие соображения закрепили решение о безгражданстве:
Поскольку веб-страницы стали более сложными и включали в себя множество графики и таблиц стилей, HTTP был дополнен флагом «keep-alive». Это позволит сохранить работоспособность сокета и позволить клиенту запрашивать несколько ресурсов с одним и тем же диалогом.
Учитывая текущую модель использования Интернета, первоначальное решение остается в силе. Иногда это может быть неудобно, но несколько небольших квантованных взаимодействий с сервером масштабируются лучше, чем незанятые сокеты.
источник
Если вы имеете в виду двунаправленные браузеры.
Причины безопасности.
Например СПАМ!
Вывод двунаправленной связи в Интернете на новый уровень
В противном случае интернет использует TCP / IP (два протокола) и UDP.
источник
Предполагается, что в настольном приложении пользователь выполняет ряд задач с определенным началом и концом. В таком приложении пользователям имеет смысл (на самом деле, не так много) войти в систему на любом сервере, предоставляющем свои данные, и оставаться в системе до завершения.
Веб-взаимодействия (как правило) не следуют той же модели. Например, на сайте электронной коммерции пользователь может получить описание продукта в результате поиска в Google и сразу же покинуть эту страницу, чтобы посмотреть предложение того же продукта на другом сайте. Или он / она может начать процесс оформления заказа, затем решить, что продукт слишком дорогой, и отказаться от него на полпути. Основная идея «гипертекста» подразумевает способность и ожидание прыгать из одного места в другое.
Постоянные соединения потребляют ресурсы. Возможно, просто сетевой сокет, возможно, пул проанализированных запросов к базе данных; все зависит от приложения. Учитывая пользователя, который может исчезнуть в любое время, не имеет смысла сохранять эти ресурсы выделенными.
На практике пользователю не нужно постоянно иметь постоянное соединение. Веб-приложение поддерживает соединения с любыми ресурсами (например, базой данных), в которых оно нуждается, и разделяет их между всеми пользовательскими запросами. Каркас веб-приложения предоставляет сеансы, которые являются ограниченными по времени местами для хранения пользовательских данных для различных запросов. Единственное, что вы не можете сделать (легко) - это иметь длительные транзакции, контролируемые клиентом, но это плохая идея даже в приложении, которое поддерживает соединения.
источник
Интернет не обязательно не имеет состояния - фактически, когда вы смотрите на Java EE - у них есть Stateful EJB и EJB без сохранения состояния.
Основная причина, по которой разработчики рекомендуют использовать архитектуру без сохранения состояния, заключается в масштабируемости. Представьте себе, что вы пытаетесь сохранить состояние всех ваших пользователей после добавления и удаления серверов для поддержки вашего трафика.
Это действительно не сложно разработать архитектуру без гражданства. Суть в том, чтобы поддерживать как можно меньшее состояние (обычно это идентификатор пользователя - предпочтительно в файле cookie) и изменять базу данных по мере необходимости.
источник
Я думаю, что это началось таким образом и просто продолжало быть таким. Теперь, когда вокруг него построено так много инфраструктуры, изменить его невозможно.
Возможно, это началось без сохранения состояния, так как поначалу соединения были менее надежными, а также была меньше пропускная способность. Если у вас мало активных подключений, вам будет проще обрабатывать больше трафика.
Пожалуйста, отредактируйте или оставьте комментарий, если у вас есть лучшая информация, или еще лучше, оставьте свой собственный ответ!
источник
Это потому, что серверы предоставляют услугу (в названии). Вы делаете запрос и получаете ответы - вот и все.
Что касается перехода к веб-разработке, я полагаю, что ASP.NET Web Forms сделает это таким образом, который будет более понятным для вас - но только потому, что он скрывает то, что на самом деле происходит под слоями абстракции.
источник
Многое можно понять, проанализировав название HTTP (HyperText Transfer Protocol). Он никогда не был разработан, чтобы быть богатым протоколом пользовательского интерфейса. Первоначальная идея состояла в том, чтобы делиться документами со ссылками между ними. Я прошу у вас документ, вы отвечаете с копией этого документа.
Первоначально в HTTP был только один глагол GET. В связи с этим он был разработан для статического контента. Зачем вам нужно указывать, когда все, что вы делаете, это запрашиваете документ, которым кто-то делится? И именно поэтому HTTP не имеет состояния ... из-за его происхождения.
источник