Понимание интернета без гражданства [закрыто]

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

Это лучшее объяснение интернета без гражданства, которое я видел:

Как я объяснил REST  моей жене
http://www.looah.com/source/view/2284

Жена: Кто такой Рой Филдинг?

Райан: Какой-то парень. Он умный.

Жена: а ? Что он сделал?

Райан: Он помог написать первые веб-серверы, а затем провел массу исследований, объясняющих, почему сеть работает так, как она работает. Его имя указано в спецификации протокола, который используется для передачи страниц с серверов в ваш браузер.

Жена: Как это работает?

Райан: Интернет?

Жена: Да.

Райан: Хм. Ну, это все довольно удивительно на самом деле. И самое смешное, что все это очень недооценено. Протокол, о котором я говорил, HTTP, он способен на всякие полезные вещи, которые люди почему-то игнорируют.

Жена: Вы имеете в виду http как начало того, что я печатаю в браузере?

Райан: Да. Эта первая часть сообщает браузеру, какой протокол использовать. То, что вы вводите, является одним из самых важных достижений в истории вычислений.

Жена: почему?

Райан: Потому что он способен описывать местоположение чего-либо в любой точке мира, из любой точки мира. Это основа Интернета. Вы можете думать об этом как GPS-координаты для знаний и информации.

Жена: Для веб-страниц?

Райан: Вообще-то. Этот парень, Рой Филдинг, много говорит о том, на что указывают эти вещи в том исследовании, о котором я говорил. Сеть построена на архитектурном стиле REST. REST предоставляет определение ресурса, на что указывают эти вещи.

Жена: веб-страница является ресурсом?

Райан: Вид. Веб-страница является представлением ресурса. Ресурсы - это просто понятия. URL - те вещи, которые вы вводите в браузер ...

Жена: я знаю, что такое URL ..

Райан: Да, верно. Они говорят браузеру, что где-то есть концепция. Затем браузер может запросить конкретное представление концепции. В частности, браузер запрашивает представление концепции на веб-странице.

Жена: Какие еще есть виды представлений?

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

Жена: Как что?

Райан: Хм. Ну, есть такая концепция, которую люди называют веб-сервисами. Это означает много разных вещей для многих людей, но основная концепция заключается в том, что машины могут использовать Интернет так же, как люди.

Жена: Это еще один робот?

Райан: Нет, не совсем. Я не имею в виду, что машины будут сидеть за столом и просматривать веб-страницы. Но компьютеры могут использовать те же протоколы для отправки сообщений друг другу. Мы занимаемся этим в течение длительного времени, но ни один из методов, которые мы используем сегодня, не работает хорошо, когда вам нужно иметь возможность общаться со всеми машинами во всем мире.

Жена: почему бы и нет?

Райан: Потому что они не были предназначены для такого использования. Когда Филдинг и его приятели начали создавать сеть, первостепенной была возможность общаться с любой машиной в любой точке мира. Большинство методов, которые мы используем на работе, чтобы заставить компьютеры общаться друг с другом, не соответствовали этим требованиям. Вам просто нужно было поговорить с небольшой группой машин.

Жена: А теперь вам нужно поговорить со всеми машинами?

Райан: Да - и больше. Мы должны иметь возможность говорить со всеми машинами обо всем, что есть на всех других машинах. Поэтому нам нужен способ, чтобы одна машина сообщала другой машине о ресурсе, который может находиться на другой машине.

Жена: что?

Райан: Допустим, вы разговариваете со своей сестрой, и она хочет одолжить уборочную машину или что-то в этом роде. Но у тебя его нет - у твоей мамы есть. Таким образом, вы говорите своей сестре, чтобы получить это от вашей мамы вместо этого. Это происходит все время в реальной жизни, и это происходит все время, когда машины тоже начинают говорить.

Жена: Так как машины сообщают друг другу, где что находится?

Райан: URL, конечно. Если все, о чем нужно говорить машинам, имеет соответствующий URL, вы создали машинный эквивалент существительного. То, что вы, я и остальной мир договорились о том, чтобы говорить о существительных определенным образом, довольно важно, а?

Жена: Да.

Райан: Машины не имеют универсального существительного - вот почему они отстой. Каждый язык программирования, база данных или другой вид системы по-разному говорят о существительных. Вот почему URL так важен. Это позволяет всем этим системам рассказывать друг другу о существительных друг друга.

Жена: Но когда я смотрю на веб-страницу, я не думаю об этом так.

Райан: Никто не делает. За исключением Филдинга и горстки других людей. Вот почему машины все еще отстой.

Жена: А как насчет глаголов, местоимений и прилагательных?

Райан: Забавно, что вы спросили, потому что это еще один важный аспект REST. Ну, глаголы в любом случае.

Жена: я просто пошутил.

Райан: Это была забавная шутка, но на самом деле это вовсе не шутка. Глаголы важны. В программировании и теории CS есть мощная концепция, называемая полиморфизмом. Это отвратительный способ сказать, что к разным существительным может применяться один и тот же глагол.

Жена: я не понимаю.

Райан: Хорошо .. Посмотри на кофейный столик. Какие существительные? Чашка, поднос, газета, пульт. Теперь, что вы можете сделать со всеми этими вещами?

Жена: я не понимаю ...

Райан: Вы можете получить их, верно? Вы можете забрать их. Вы можете опрокинуть их. Вы можете сжечь их. Вы можете применить те же самые точные глаголы к любому из объектов, которые там сидят.

Жена: Хорошо ... так?

Райан: Ну, это важно. Что если бы вместо меня была возможность сказать вам: «возьми чашку», «возьми газету» и «возьми пульт»; что если вместо этого нам нужно придумать разные глаголы для каждого из существительных? Я не мог использовать слово «получить» повсеместно, но вместо этого мне пришлось придумывать новое слово для каждой комбинации глагол / существительное.

Жена: Вау! Это странно.

Райан: Да, это так. Наш мозг достаточно умен, чтобы знать, что одни и те же глаголы могут применяться ко многим существительным. Некоторые глаголы более специфичны, чем другие, и применяются только к небольшому набору существительных. Например, я не могу водить чашку и не могу пить машину. Но некоторые глаголы почти универсальны, как GET, PUT и DELETE.

Жена: Вы не можете УДАЛИТЬ чашку.

Райан: Хорошо, хорошо, но вы можете выбросить это. Это была еще одна шутка, верно?

Жена: Да.

Райан: Так или иначе, HTTP - этот протокол, созданный Филдингом и его друзьями - это все о применении глаголов к существительным. Например, когда вы переходите на веб-страницу, браузер выполняет HTTP-GET для URL-адреса, который вы вводите, и возвращается веб-страница.

Веб-страницы обычно имеют изображения, верно? Это отдельные ресурсы. Веб-страница просто указывает URL-адреса к изображениям, и браузер запускает и выполняет для них больше HTTP GET, пока все ресурсы не будут получены и веб-страница не отобразится. Но здесь важно то, что к разным существительным можно относиться одинаково. Является ли существительное изображение, текст, видео, mp3, слайд-шоу, что угодно. Я могу получить все эти вещи таким же образом, учитывая URL.

Жена: Похоже, GET - довольно важный глагол.

Райан: Это так. Особенно, когда вы используете веб-браузер, потому что браузеры в основном просто ПОЛУЧАЮТ вещи. Они не делают много других видов взаимодействия с ресурсами. Это проблема, потому что многие люди считают, что HTTP предназначен только для GETing. Но HTTP - это протокол общего назначения для применения глаголов к существительным.

Жена: Круто. Но я до сих пор не понимаю, как это что-то меняет. Какие виды существительных и глаголов вы хотите?

Райан: Ну, существительные есть, но не в правильном формате.

Подумайте, когда вы просматриваете amazon.com в поисках вещей, чтобы купить меня на Рождество. Представьте, что каждый из продуктов является существительным. Теперь, если бы они были доступны в виде, понятном машине, вы могли бы сделать много полезных вещей.

Жена: Почему машина не может понять нормальную веб-страницу?

Райан: Потому что веб-страницы предназначены для понимания людьми. Машина не заботится о макете и стиле. Машины в основном просто нужны данные. В идеале каждый URL должен иметь удобочитаемое и машиночитаемое представление. Когда машина получает ресурс, она запрашивает машиночитаемый. Когда браузер получает ресурс для человека, он запрашивает читабельный.

Жена: Значит, людям придется создавать машинные форматы для всех своих страниц?

Райан: Если бы это было ценно.

Слушай, мы говорили об этом с большой абстракцией. Как насчет того, чтобы взять реальный пример. Вы учитель - в школе я уверен, что у вас есть большая компьютерная система или, скорее всего, три или четыре компьютерные системы, которые позволяют вам управлять учащимися: в каких классах они учатся, какие классы они получают, экстренные контакты, информация о книгах, из которых вы учите, и т. д. Если системы основаны на сети, то, вероятно, здесь есть URL для каждого существительного, участвующего здесь: студент, учитель, класс, книга, комната и т. д. Прямо сейчас, чтобы получить URL через браузер дает вам веб-страницу. Если бы для каждого URL существовало машиночитаемое представление, то было бы просто защелкнуть новые инструменты в системе, потому что вся эта информация была бы потребляемой стандартным способом. Также было бы намного проще для каждой из систем общаться друг с другом. Или вы могли бы создать государственную или общенациональную систему, которая могла бы общаться с каждой из отдельных школьных систем для сбора результатов тестирования. Возможности безграничны.

Каждая из систем будет получать информацию друг от друга, используя простой HTTP GET. Если одной системе нужно что-то добавить в другую, она будет использовать HTTP POST. Если система хочет обновить что-то в другой системе, она использует HTTP PUT. Осталось выяснить, как должны выглядеть данные.

Жена: Так над чем вы и все компьютерные люди работаете сейчас? Решаете, как должны выглядеть данные?

Райан: К сожалению, нет. Вместо этого подавляющее большинство заняты написанием слоев сложных спецификаций для выполнения этих вещей другим способом, который не так полезен или красноречив. Существительные не универсальны, а глаголы не полиморфны. Мы отбрасываем десятилетия реального использования в полевых условиях и проверенной техники и начинаем с того, что очень похоже на другие системы, которые потерпели неудачу в прошлом. Мы используем HTTP, но только потому, что это помогает нам меньше общаться с сетью и людьми, занимающимися вопросами безопасности. Мы торгуем простотой для ярких инструментов и мастеров.

Жена: почему?

Райан: Понятия не имею.

Жена: Почему бы тебе не сказать что-нибудь?

Райан: Может быть, я буду.

Как, по-вашему, можно было бы хранить состояние миллиардов миллиардов миллиардов миллиардов соединений? :) Таким образом, вы сохраняете состояние только там, где это необходимо, в сессиях.

Кстати: HTTP не без соединения.

Как разработчик настольных систем, вам может быть удобнее использовать богатый пользовательский интерфейс. Переход в Интернет может показаться шагом назад. В веб-мире свободы творчества меньше, и это может дать вам чувство стеснения. Не позволяйте этому сбить вас с толку! Существует ряд вещей, которые могут помочь вам осуществить переход, и вот их краткий список:

1. Состояние может быть общим, но оно часто хранится на сервере и на него ссылаются токены, такие как идентификаторы сеанса, параметры URL, скрытые поля или значения cookie.
2. Модели без состояний хорошо подходят для обработки транзакций. Попробуйте построить свою модель таким образом, чтобы уменьшить количество требуемого состояния. В ACID принципы обработки транзакций могут помочь вам достичь этого.
3. Ознакомьтесь с шаблоном MVC (если вы еще этого не сделали). Это поможет улучшить ваш дизайн, поддерживая разделение интересов. Некоторые популярные платформы, такие как Struts (Java) и MVC (.NET), построены вокруг этой концепции.
4. Подумайте об использовании плагина, такого как Java , Flash или Silverlight, для сверхбогатого пользовательского интерфейса. Для полуобогащенного опыта рассмотрите возможность использования популярных библиотек на основе java-скриптов, таких как JQuery или AJAX .

Удачного программирования!

Потому что было время, когда не было миллионов и миллионов веб-страниц. Потому что было время, когда только в университетах и ​​исследовательских центрах было несколько страниц. Было время, когда не было широкополосного доступа, и http был передан через 1200 бод-модемов, установленных на настольных телефонах. Было время, когда «богатым веб-приложениям» требовалась, по их мнению, нелепая полоса пропускания. И помните, TCP / IP был создан, потому что ранний интернет был очень ненадежным.

HTTP 1.0 был в начале 1990-х годов. Подумайте о том, каким был Интернет тогда, и почему они разработали его так, как они это сделали.

Все вроде развивалось. Интернет существовал до появления веб-браузеров и Интернета. Это был кипящий горшок с ftp, телнетом, сусликом, пингом, пальцем и несколькими другими битами и бобами. Первый веб-браузер, Mosaic (я думаю, это было очень давно, 1991, я думаю, я учился в колледже), действовал как своего рода путаница между ftp и средством просмотра документов. Волшебство произошло в том, что у вас могли быть ссылки в документе, которые открывали бы новый документ.

Вся интерактивность, которую мы сейчас развили в течение следующих 20 лет. Это была не счастливая эволюция. У нас были войны браузеров, IE и Netscape решили использовать его для контроля над стандартами (упрощение;)), и различные другие третьи стороны начали внедрять плагины для обеспечения насыщенного контента. Ява собиралась стать волшебной пулей и, конечно, Flash. Кто-нибудь помнит плагины VRML, которые обещали 3d-миры и поставили ровно полдюжины 3d-моделей моделей Star Wars?

Я немного увлекся к концу, но вы поняли идею :)

Основные причины связаны с сочетанием того, что, по мнению ацетемии, было целью HTTP, и соображениями масштабируемости. Первоначально HTML был разработан для обмена информацией или тезисами за пределами академических границ. Это был чисто стилизованный текст. Только когда первый браузер позволил вам показывать картинки, люди начали думать за пределами этой модели.

Следующие соображения закрепили решение о безгражданстве:

• Типичное взаимодействие должно было быть быстрой загрузкой и чтением. Во время задержки до следующего запроса сокет будет сидеть без дела.
• Сокеты занимают драгоценные системные ресурсы. Если бы нам не приходилось вести диалог, как с SMTP, вы могли бы многое сделать, чтобы одна машина обслуживала тысячи клиентов.
• Они уже извлекли ценные уроки из управления учетными записями удаленной оболочки, NFS, SMTP и другими протоколами подключения с отслеживанием состояния.

Поскольку веб-страницы стали более сложными и включали в себя множество графики и таблиц стилей, HTTP был дополнен флагом «keep-alive». Это позволит сохранить работоспособность сокета и позволить клиенту запрашивать несколько ресурсов с одним и тем же диалогом.

Учитывая текущую модель использования Интернета, первоначальное решение остается в силе. Иногда это может быть неудобно, но несколько небольших квантованных взаимодействий с сервером масштабируются лучше, чем незанятые сокеты.

Если вы имеете в виду двунаправленные браузеры.

Причины безопасности.

Например СПАМ!

Вывод двунаправленной связи в Интернете на новый уровень

В противном случае интернет использует TCP / IP (два протокола) и UDP.

Протокол управления передачей(TCP) является одним из основных протоколов Internet Protocol Suite. TCP является одним из двух исходных компонентов пакета, дополняющих Интернет-протокол (IP), и поэтому весь пакет обычно называется TCP / IP. TCP предоставляет сервис обмена данными напрямую между двумя хостами в одной сети, тогда как IP обрабатывает адресацию и маршрутизацию сообщений в одной или нескольких сетях. В частности, TCP обеспечивает надежную упорядоченную доставку потока байтов из программы на одном компьютере в другую программу на другом компьютере. TCP - это протокол, на который опираются основные интернет-приложения, такие как World Wide Web, электронная почта и передача файлов. Другие приложения, которые не требуют надежного обслуживания потока данных,

Интернет-протокол(IP) - это основной протокол связи, используемый для ретрансляции дейтаграмм (пакетов) через межсетевую сеть с использованием Internet Protocol Suite. Ответственный за маршрутизацию пакетов через границы сети, это основной протокол, который устанавливает Интернет. IP является основным протоколом на уровне Интернета пакета интернет-протоколов и имеет задачу доставки дейтаграмм с исходного хоста на конечный хост исключительно на основе их адресов. Для этой цели IP определяет методы адресации и структуры для инкапсуляции дейтаграмм. Исторически IP был службой дейтаграмм без установления соединения в первоначальной Программе управления передачей, представленной Винтом Серфом и Бобом Каном в 1974 году, а другой - протоколом управления передачей (TCP) с установлением соединения. Поэтому пакет интернет-протокола часто называют TCP / IP.

Предполагается, что в настольном приложении пользователь выполняет ряд задач с определенным началом и концом. В таком приложении пользователям имеет смысл (на самом деле, не так много) войти в систему на любом сервере, предоставляющем свои данные, и оставаться в системе до завершения.

Веб-взаимодействия (как правило) не следуют той же модели. Например, на сайте электронной коммерции пользователь может получить описание продукта в результате поиска в Google и сразу же покинуть эту страницу, чтобы посмотреть предложение того же продукта на другом сайте. Или он / она может начать процесс оформления заказа, затем решить, что продукт слишком дорогой, и отказаться от него на полпути. Основная идея «гипертекста» подразумевает способность и ожидание прыгать из одного места в другое.

Постоянные соединения потребляют ресурсы. Возможно, просто сетевой сокет, возможно, пул проанализированных запросов к базе данных; все зависит от приложения. Учитывая пользователя, который может исчезнуть в любое время, не имеет смысла сохранять эти ресурсы выделенными.

На практике пользователю не нужно постоянно иметь постоянное соединение. Веб-приложение поддерживает соединения с любыми ресурсами (например, базой данных), в которых оно нуждается, и разделяет их между всеми пользовательскими запросами. Каркас веб-приложения предоставляет сеансы, которые являются ограниченными по времени местами для хранения пользовательских данных для различных запросов. Единственное, что вы не можете сделать (легко) - это иметь длительные транзакции, контролируемые клиентом, но это плохая идея даже в приложении, которое поддерживает соединения.

Интернет не обязательно не имеет состояния - фактически, когда вы смотрите на Java EE - у них есть Stateful EJB и EJB без сохранения состояния.

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

Это действительно не сложно разработать архитектуру без гражданства. Суть в том, чтобы поддерживать как можно меньшее состояние (обычно это идентификатор пользователя - предпочтительно в файле cookie) и изменять базу данных по мере необходимости.

Я думаю, что это началось таким образом и просто продолжало быть таким. Теперь, когда вокруг него построено так много инфраструктуры, изменить его невозможно.

Возможно, это началось без сохранения состояния, так как поначалу соединения были менее надежными, а также была меньше пропускная способность. Если у вас мало активных подключений, вам будет проще обрабатывать больше трафика.

Пожалуйста, отредактируйте или оставьте комментарий, если у вас есть лучшая информация, или еще лучше, оставьте свой собственный ответ!

Это потому, что серверы предоставляют услугу (в названии). Вы делаете запрос и получаете ответы - вот и все.

Что касается перехода к веб-разработке, я полагаю, что ASP.NET Web Forms сделает это таким образом, который будет более понятным для вас - но только потому, что он скрывает то, что на самом деле происходит под слоями абстракции.

Многое можно понять, проанализировав название HTTP (HyperText Transfer Protocol). Он никогда не был разработан, чтобы быть богатым протоколом пользовательского интерфейса. Первоначальная идея состояла в том, чтобы делиться документами со ссылками между ними. Я прошу у вас документ, вы отвечаете с копией этого документа.

Первоначально в HTTP был только один глагол GET. В связи с этим он был разработан для статического контента. Зачем вам нужно указывать, когда все, что вы делаете, это запрашиваете документ, которым кто-то делится? И именно поэтому HTTP не имеет состояния ... из-за его происхождения.