Позвольте мне начать с
краткого 10-минутного введения в «Основы сетевого взаимодействия».
Учитывая тот факт, что у нас мало времени,
я бы
сосредоточился на предоставлении вам необходимых для понимания каждой из тем.
Теперь, то, что мы рассматриваем в данном конкретном модуле, потребует,
по крайней мере, элементарного понимания того, как
работает компьютерная сеть, прежде чем мы поймем,
почему нам нужно использовать HTTP, почему мы общаемся с сервером,
в чем причина задержки, когда вы общаетесь с сервером и так далее.
Кроме того, различные протоколы, о которых вы
должны знать, прежде чем вы сможете даже общаться с сервером.
Итак, имея в виду все это,
10-минутное краткое введение в Основы работы с сетями.
Мы начинаем понимать, что веб-приложения больше не являются автономными. У
них всегда есть цитата конец цитаты Cloud бэкэнд, поддерживающий ваше веб-приложение.
Теперь в эти дни все находится на облаке.
Довольно скоро вы тоже окажетесь в Облаке,
по крайней мере, на облаке девять с серебряной подкладкой.
Но, учитывая, что нам
нужна поддержка на стороне сервера, чтобы наше угловое приложение работало правильно,
там вы бы разместили сервер.
И в наши дни хостинг сервера очень
легко сделать с помощью одного из облачных инфраструктурных сервисов,
таких как Amazon Web Services, Heroku или Digital
Ocean или многие другие, которые обеспечивают поддержку облачных серверов.
Итак, что именно доступно на стороне сервера?
Обычно у вас есть серверный интерфейс, который разговаривает с вашим угловым приложением,
так что это логика сервера, а за кулисами логика сервера взаимодействует с
постоянным хранилищем, таким как база данных, в которой хранятся и извлекаются ваши данные.
Когда вы войдете в сетевой мир,
вы довольно скоро будете бомбардированы 304 маленькими акронимами,
вещами, которые, как вы думали, вы знали, что они были из обычного английского языка, или они имеют
совершенно другое значение или
цель, когда вы сталкиваетесь с ними в этом сетевом мире.
Итак, давайте рассмотрим несколько из них.
Таким образом, в сетевом мире вы услышите людей, говорящих по протоколу HTTP.
Протокол, используемый для связи между клиентом и сервером.
Это протокол уровня приложений, о котором мы кратко
расскажем чуть больше в остальной части этой лекции.
Протокол HTTP для его работы нуждается в URL-адресе, который будет предоставлен ему,
Единый локатор ресурсов.
Таким образом, это строка символов, разделенных косой чертой,
с двоеточием HTTP или двоеточием HTTPS, прикрепленным перед ним.
И я уверен, что если вы использовали World Wide Web,
вы довольно знакомы с тем, как выглядят URL-адреса.
Теперь, кроме того, вы услышите, как люди говорят о JSON,
а не о вашем друге Джейсоне, а о JavaScript Object Notation.
Таким образом, обозначение объектов JavaScript - это один из способов кодирования данных, которые
отправляются со стороны сервера на сторону клиента или наоборот.
А также вы услышите, как люди говорят о XML еще одном способе
кодирования данных во время транспортировки между клиентом и сервером.
Теперь вы также услышите, как люди говорят о протоколах более высокого уровня под названием SOAP,
а не о том, с которым вы принимаете душ, но SOAP как протокол, который
позволяет обмениваться данными между объектами распределения в их сети.
А также, вы услышите, как люди говорят о REST,
а не о том, что вы получаете слишком много прохождения этого конкретного курса,
REST или репрезентационного государственного перевода. В этом
модуле у меня будет более короткая лекция, специально посвященная REST.
И в мире HTTP
вы услышите, как люди говорят о GET, PUT
, POST и DELETE, и вам будет интересно,
что они все означают?
Давайте узнаем немного об
этом в этой лекции, а также лекции по REST, которую вы увидите немного позже.
Одна важная вещь, которую вы должны понять, когда вы
общаетесь с сервером, заключается в том, что связь с клиентским сервером
вызывает неожиданное количество задержек или неопределенное количество задержки,
пока данные либо извлекаются, либо загружаются на сервер с сайта клиента.
Таким образом, это означает, что в приложении вашего клиентского сайта
вам нужно держать пользователя в курсе того, что
что-то происходит за кулисами и
иметь возможность обрабатывать задержки и,
возможно, не иметь возможности получить данные со стороны сервера.
Вполне возможно, что при попытке подключиться к серверу
подключение сервера может произойти сбой,
сервер может возвращать неверные данные или может вызвать ошибку в связи.
Все это должно быть обработано на клиентской стороне соответствующим образом, чтобы
ваше приложение по-прежнему работало даже при наличии этих проблем.
Переход к наиболее популярному протоколу уровня приложений,
используемому для связи между клиентом и сервером, протоколу
Hypertext Transfer Protocol.
Но это протокол связи с клиентским сервером.
Теперь это может иметь или не может
иметь большого смысла для вас, если у вас нет достаточного фона в сети,
но это протокол, который используется для кодирования сообщений, которые вы
обменивались между вашим клиентским приложением, которое
является угловым приложением в этом случае и на стороне сервера.
Таким образом, этот протокол HTTP позволяет
извлекать документы на основе гипертекста со стороны сервера,
все чаще информация, загружаемая со стороны сервера,
кодируется в одном из стандартных форматов кодирования, таких как JSON или XML.
И для того, чтобы иметь возможность общаться с сервером,
у вас есть поддержка от различных HTTP-действий или то, что мы называем HTTP-глаголами,
HEAD, GET, POST,
PUT, DELETE, TRACE, OPTIONS и CONNECT.
Мы увидим, в частности, GET, PUT, POST
и DELETE глаголы более подробно, когда мы рассмотрим протокол REST API немного позже.
Как работает протокол HTTP?
В протоколе HTTP
вы отправляете запрос GET из клиентского приложения на сервер.
И это кодируется в виде сообщения HTTP-запроса.
Сообщение запроса обычно содержит URL-адрес
в сообщении запроса, указывающий, что вы хотите, чтобы сервер отправил вам.
И это обычно сообщение GET, если вы хотите,
чтобы данные были загружены со стороны сервера.
Вы также укажете, с каким конкретным сервером вы общаетесь.
Когда сервер получает ваш запрос,
сервер извлекает данные из своего хранилища данных,
обычно базы данных на стороне сервера,
а затем упаковывает эти данные в
соответствующем формате и отправляет их обратно вам на стороне клиента.
Если вы получаете стандартный
код HTML, CSS и JavaScript со стороны сервера,
то ваш браузер может отобразить это.
Но с такими приложениями, как Angular,
вы в основном
подключаетесь к серверу, а затем извлекаете данные в виде JSON или XML большую часть времени.
За исключением первоначальной загрузки всех ресурсов, необходимых
для вашего углового приложения, которое будет выполняться в вашем браузере.
Как мы видели ранее,
HTTP-приложение требует отправки сообщений между клиентом и сервером.
Сообщение запроса обычно отправляется от клиента на сервер, и
сообщение запроса состоит из строки запроса плюс куча заголовков,
где вы предоставляете дополнительную информацию для квалификации запроса.
Мы увидим использование различных заголовков и настроек в заголовках
, как мы проходим через некоторые из упражнений в этом конкретном модуле.
Строка запроса и заголовки отделяются от тела
сообщения запроса одной пустой строкой.
Тело сообщения может содержать дополнительные данные,
особенно если ваш клиент отправляет данные на сторону сервера.
Например, при отправке формы
информация внутри формы кодируется в
формат JSON, а затем отправляется на сторону сервера со стороны клиента.
Таким образом, это будет сделано с помощью POST или PUT сообщения.
Глядя на немного более подробную информацию о сообщении запроса HTTP,
типичное сообщение запроса в
строке запроса будет содержать метод, который является либо GET, PUT, POST,
DELETE или некоторые из других глаголов, которые вы видели ранее,
а затем URL-адрес и версия Протокол HTTP, который вы используете для связи с клиентом на стороне сервера.
Поле заголовка обычно содержит имя поля заголовка,
двоеточие и значение этого поля заголовка.
И содержимое тела, как я уже упоминал,
может быть закодировано либо в формате JSON, либо в формате XML.
Ниже приведен пример
типичного сообщения HTTP-запроса, которое может быть отправлено на сервер от клиента.
Поэтому в этом конкретном сообщении запроса
мы просим сервер сохранить страницу index.html со
стороны сервера на стороне клиента, чтобы ее
можно было отобразить в браузере на стороне клиента.
Такой запрос обычно имеет пустое тело в сообщении запроса.
Большая часть информации будет закодирована
в строке запроса плюс заголовки сообщения запроса.
Когда клиент отправляет запрос на сервер.
Сервер обрабатывает запрос, а затем отправляет ответ на клиентскую сторону.
Ответное сообщение организовано снова, три части,
строка состояния, где
хранится некоторая информация о том, как запрос был обработан и что отправляется обратно клиенту,
заголовки будут содержать дополнительные сведения о том, что
содержится в ответном сообщении, а затем , за которой следует пустая строка,
а затем фактическое тело сообщения.
Пример того, что обычно содержится в ответном сообщении HTTP,
в этом случае это ответное сообщение возвращается с 200,
который является кодом состояния сообщения.
Если вы видите 200 в строке запроса как код состояния,
это означает, что ваш запрос был успешным, и сервер может
вернуть запрошенные данные со стороны сервера.
И тогда заголовок будет содержать дополнительные указания
на сторону клиента, включая информацию о
том, как кодируется фактическое тело сообщения.
Затем тело может содержать,
если вы запросили страницу index.html,
тело сообщения будет содержать HTML-код для
страницы index.html, как вы видите в этом примере.
Одна из частей информации в строке состояния, которую я называю кодом состояния.
Если сервер сможет правильно обработать ваш запрос,
он отправит обратно ответ с кодом состояния 200,
что означает, что все в порядке на стороне сервера, и
сторона сервера возвращает данные правильно.
Если сервер не может обработать запрос по какой-либо причине,
то эта информация будет закодирована
в коде состояния в строке состояния ответного сообщения.
Различные коды состояния, обычно встречающиеся при
получении ответа от сервера включают 201,
что означает, что при попытке создать
объект на стороне сервера он был успешно создан,
или 301, что означает, что все, что вы запрашиваете, перемещено постоянно
в новое местоположение, и URL-адрес
нового местоположения этого ресурса будет возвращен на клиентскую сторону.
400 и 500 обычно указывают на то, что на стороне сервера есть некоторая проблема.
404 - это то, что вы часто сталкиваетесь, когда
запрашиваете что-то, что не существует на стороне сервера.
Аналогичным образом 500 означает, что сервер просто сдается,
он не может обработать ваш запрос, а затем отправляет обратно внутреннюю ошибку сервера.
Это два распространенных кода ошибок, с которыми вы столкнетесь.
Остальные имеют конкретное значение, как указано в этой таблице.
Есть больше, чем коды состояния, которые я дал вам в этой таблице,
но это некоторые из наиболее распространенных кодов состояния, с которыми вы
столкнетесь в ответном сообщении, поступающем со стороны сервера.
Еще один момент, который я упомянул, заключается в том, что сервер может кодировать
данные в определенном формате, таком как XML или расширенный язык разметки или JSON,
формат нотации объектов JavaScript.
Теперь, как правило, в этом конкретном курсе,
мы будем иметь дело с данными, которые кодируются в основном в JSON.
Большинство клиентских приложений,
включая мобильные приложения в эти дни, как правило, связываются с
сервером, и формат обмена данными по умолчанию является JSON.
Вот почему я потрачу несколько минут, объясняя вам о JSON.
Обозначение объектов JavaScript или JSON представляет собой легкий формат обмена данными.
Причина, по которой формат данных JSON особенно
интересен нам в этом курсе, заключается в том, что обозначение объектов JavaScript,
как следует из названия,
очень легко сопоставляется с объектом JavaScript, который вы используете с любым кодом JavaScript.
Таким образом,
преобразование объекта JavaScript в нотацию JSON и наоборот очень просто.
Обозначение JSON - это то, что мы называем
самоописательной и очень легкой для понимания нотацией.
В формате JavaScript Object Notation
данные структурированы очень чистым, определенным образом.
Это структурировано как набор пар имен, значений,
и это структурировано как упорядоченный список значений.
Вы можете увидеть пример этого с правой стороны здесь.
Мы фактически использовали эти данные JSON в нашем угловом приложении уже ранее.
Итак, теперь вы видите, почему данные структурированы таким образом.
И вы также понимаете, что очень легко иметь дело с
этими данными в вашем JavaScript или вашем коде TypeScript в вашем угловом приложении.
С помощью этого я завершаю краткий обзор основ сети.