Позвольте мне начать с краткого 10-минутного знакомства
с основными основами сетевого взаимодействия.
Чем больше я преподаю английский язык, тем больше я понимаю, что просто для использования своих самых красивых особенностей
углового, вам нужно иметь понимание так много различных связанных FINs
, прежде чем вы сможете даже понять, что вы делаете с угловым.
К моменту, когда вы начнете преследовать каждый из этих FINS,
они станут целыми курсами самостоятельно и довольно скоро,
я в конечном итоге преподаю всю свою учебную программу компьютерных наук вам.
Но учитывая тот факт, что у нас есть ограниченное время,
я сосредоточусь на предоставлении вам основных
, которые вам нужны для понимания каждой из тем.
Теперь, то, что мы рассматриваем в этом конкретном модуле, потребует
хотя бы элементарного понимания того, как работает компьютерная сеть
, прежде чем мы поймем, почему нам нужно использовать HTTP,
, почему мы общаемся с сервером.
Причина задержки заключается в том, что когда вы разговариваете с сервером,
и так далее.
А также различные протоколы, которые вам нужно знать
, прежде чем вы сможете даже общаться с сервером.
Итак, имея все это в виду,
10-минутная краткая знакомство с основными положениями нетворкинга.
Мы начинаем понимать, что веб-приложения больше не являются автономными.
У них всегда есть конец цитаты облачной серверной части, поддерживающей ваше веб-приложение.
Теперь, в эти дни все находится в облаке.
Довольно скоро вы тоже будете на облаке, по крайней мере, на облаке девять с серебряной подкладкой.
Но учитывая, что нам нужна поддержка Silverside для нашего углового приложения, чтобы работать правильно,
там бы вы разместили сервер.
И в наши дни хостинг сервера очень легко сделать с помощью одного
облачных инфраструктурных сервисов.
Такие вещи, как Amazon, Web Services, Heroku или Digital Ocean
или многие другие, которые обеспечивают поддержку облачных серверов
, которую вы можете использовать для обеспечения поддержки серверов для вашего углового приложения.
Итак, на стороне сервера, что именно доступно на стороне сервера?
Обычно у вас есть интерфейс сервера, который разговаривает с вашим угловым приложением.
Итак, это логика сервера и за кулисами,
логика сервера взаимодействует с постоянным хранилищем, таким как база данных
, где ваши данные хранятся и извлекаются.
Когда вы войдете в мир нетворкинга, вы скоро будете бомбардированы
с 304 маленькими аббревиатурами.
Вещи, которые вы думали, что знаете, что они из обычного английского
или они имеют совершенно другое значение
или цели, когда вы сталкиваетесь с ними в мире сетей.
Итак, давайте рассмотрим несколько из них.
Итак, в мире сетей вы услышите, как люди говорят по протоколу HTTP.
Протокол, используемый для связи между клиентом и сервером.
Это протокол уровня приложения
, о котором мы кратко расскажем немного больше в остальной части этой лекции.
Протокол HTTP для его работы нуждается в URL-адресе,
Единый локатор ресурсов.
Итак, это строка символов, разделенных косой чертой с каждым двоеточием TTP,
на https: прикрепленный перед ним.
И я уверен, что если вы используете всемирную паутину,
вы довольно знакомы с тем, как выглядят URL-адреса.
Теперь, кроме того, вы услышите, как люди говорят о JSON,
не к вашему другу Джейсону, а к JavaScript Object Notation.
Таким образом, нотация объектов JavaScript является одним из способов кодирования данных, которые отправляются
со стороны сервера на сторону клиента или наоборот.
А также вы услышите людей, говорящих о XML,
еще одном способе кодирования данных, пока он находится в транзитной отправке
между клиентом и сервером сайта.
Теперь, а также вы услышите людей, говорящих о протоколах более высокого уровня, называемых SOAP,
не тот вид, с которым вы принимаете душ, но SOAP как протокол
, который позволяет общаться между объектами распределения внутри сети.
А также вы услышите, как люди говорят о REST, а не о чем-то
, что вы получаете слишком много пройти через этот конкретный курс.
REST или передача представительного состояния.
У меня будет более короткая лекция специально посвящена
REST немного позже в этом модуле.
И в мире HTTP вы услышите, как люди говорят о GET,
PUT, POST и DELETE, и вам будет интересно,
, что они все означают?
Давайте узнаем немного об этом в этой лекции
, а также лекцию на REST, которую вы увидите немного позже.
Одна важная вещь, которую вы должны понять, когда вы общаетесь
с сервером заключается в том, что связь клиентского сервера вызывает неожиданное количество задержек
или неопределенное количество задержки
в то время как данные либо извлекаются, либо загружаются на сервер со стороны клиента.
Итак, что означает, что в вашем клиент-серверном приложении
вам нужно держать пользователя в курсе того факта
, что что-то происходит за кулисами и уметь справляться с задержками
и, возможно, не в состоянии получить данные со стороны сервера.
Вполне возможно, что при попытке подключиться к серверу
соединение с сервером может завершиться неудачей,
сервер может вернуть неверные данные или может вызвать ошибку в общении.
Все это должно обрабатываться на стороне клиента соответствующим образом, чтобы
, что ваше приложение все равно будет работать даже при наличии этих проблем.
Переход в самый популярный протокол уровня приложений, используемый для связи
между клиентом и сервером, протокол передачи гипертекста
, но это протокол связи клиентского сервера.
Теперь, это может иметь или не иметь большого смысла для вас
, если у вас нет достаточного фона в сети, но это протокол
, который используется для кодирования сообщений, которые вы обмениваетесь между вашим клиентским приложением,
, которое в этом случае является угловым приложением, и серверной стороной.
Таким образом, этот протокол HTTP позволяет извлекать документы на основе гипертекста
со стороны сервера все чаще информация, загружаемая
со стороны сервера, кодируется в одном из стандартных форматов кодирования, таких как JSON или XML.
И, для того, чтобы иметь возможность говорить с сервером,
у вас есть поддержка различных HTTP-действий,
или то, что мы называем HTTP-глаголами: HEAD, GET, POST,
PUT, DELETE, TRACE, OPTIONS и CONNECT.
Мы увидим, в частности, глаголы GET, PUT, POST и DELETE более подробно
, когда мы рассмотрим остальной протокол API немного позже.
Как работает протокол HTTP?
В протоколе HTTP вы отправляете запрос от вашего клиентского приложения на сервер
и это кодируется в виде сообщения HTTP-запроса.
Сообщение запроса обычно содержит URL-адрес в сообщении запроса, указывающий,
, что это такое, что вы хотите с серверной стороны отправить вам
, и это обычно сообщение GET
, если вы хотите, чтобы данные были загружены с сайта сервера.
И вы также укажете, с каким именно сервером вы общаетесь.
Когда сервер получает ваш запрос, сервер
извлекает данные из своего хранилища данных, как правило, базы данных на стороне сервера,
, а затем упаковывает эти данные в соответствующие четыре обратно,
и отправляет данные обратно вам на стороне клиента.
Если вы получаете стандартный код HTML, CSS и javascript со стороны сервера,
, то ваш браузер может сделать это.
Вернувшись с приложениями, такими как угловые, вы в основном подключаетесь к серверу
, а затем извлекаете данные в виде либо JSON, либо XML большую часть времени.
За исключением первоначальной загрузки всех ресурсов
, необходимых для выполнения углового приложения в вашем браузере.
Итак, как мы видели ранее, HTTP-приложение требует отправки сообщений
между клиентом и сервером.
Сообщение запроса, обычно отправляемое клиентом на сервер,
и сообщение запроса состоит из строки запроса плюс куча заголовков
, где вы предоставите дополнительную информацию для квалификации запроса.
Мы увидим использование различных заголовков
и настроек в заголовках, как мы проходим через некоторые
упражнений в этом конкретном модуле.
Строка запроса и заголовки отделены
от тела сообщения запроса одной пустой строкой.
Тело сообщения может содержать дополнительные данные, особенно
, если ваши клиенты отправляют данные на сервер.
Например, при отправке формы
информация в форме кодируется в формате JSON
, а затем передается на стороне сервера со стороны клиента.
Таким образом, это будет сделано с использованием сообщения POST или PUT.
Глядя на немного более подробную информацию о HTTP-запросе,
типичное сообщение запроса в строке запроса будет содержать метод,
, который является либо GET, PUT, PAUSE, DELETE
, либо некоторые другие глаголы, которые вы видели ранее.
Затем следует URL-адрес и версия протокола HTTP
, который вы используете для связи с клиентом на стороне сервера.
Поле заголовка обычно содержит имя поля заголовка, двоеточие,
и значение этого поля заголовка.
И содержимое тела, как я уже упоминал, может быть закодировано либо в формате JSON, либо в формате XML.
Вот пример типичного сообщения HTTP-запроса
, которое может быть отправлено на сервер от клиента.
Итак, в этом конкретном сообщении запроса мы просим сервер сохранить
и index.hmtl страницы со стороны сервера на сторону клиента так
, что его можно отобразить в браузере на стороне клиента.
Подобный запрос обычно имеет пустое тело в сообщении запроса.
Большая часть информации будет закодирована в строке запроса плюс заголовки
сообщения запроса.
Когда клиент отправляет запрос на сервер,
сервер обрабатывает запрос, а затем отправляет ответ на клиентскую сторону.
Ответное сообщение состоит из, опять же, трех частей.
Сохраняется строка состояния с некоторой информацией о том, как был обработан запрос
и что отправляется обратно клиенту.
Заголовки будут содержать дополнительные сведения о том, что содержится в ответном сообщении
, а затем следует пустая строка, а затем фактическое тело сообщения.
Пример того, что обычно содержится в сообщении ответа HTTP.
В этом случае ответное сообщение возвращается с 200
, который является кодом состояния сообщения.
Если вы видите здесь, 200 в строке запроса как код состояния.
Это означает, что ваш запрос был успешным
и сервер может вернуть данные, которые вы запросили со стороны сервера.
И затем заголовок будет содержать дополнительные направления на клиентскую сторону,
, включая информацию о том, как кодируется фактическое тело сообщения.
Затем тело может содержать, если вы запросили индекс HTML страницы,
тело сообщения будет содержать код HTML
для начальной страницы индекса HTML, как вы видите в этом примере здесь.
Одна из частей информации в строке состояния, которую я называю кодом состояния.
Если сервер сможет обработать ваш запрос правильно,
он отправит обратно ответ с оценкой состояния 200,
означает, что все в порядке на стороне сервера,
и серверная сторона вернет данные правильно.
Если сервер не может обработать запрос по какой-либо причине,
, то эта информация будет закодирована в коде состояния в
в строке состояния ответного сообщения.
Различные коды состояния, как правило, что вы столкнетесь
при получении ответа со стороны сервера,
включают 201, что означает, что когда вы пытаетесь создать объект на стороне сервера,
он был успешно создан или 301, что означает, что все, что вы запрашиваете
имеет переехал навсегда в новое место,
и что вы находитесь на новом месте этого ресурса
, будет возвращен на вашу клиентскую сторону.
400s и 500s обычно указывают на некоторые проблемы на стороне сервера.
A 404 - это то, с чем вы часто сталкиваетесь, когда запрашиваете
для чего-то, что не существует на стороне сервера.
Аналогично, 500 означает, что сервер просто сдается,
он не может обработать ваш запрос, а затем отправляет обратно внутреннюю ошибку сервера.
Это два распространенных кода ошибок, с которыми вы столкнетесь.
Остальные имеют конкретное значение, как указано в этой таблице.
Есть больше, чем коды состояния, которые я дал вам в этой таблице
, но это некоторые из наиболее распространенных кодов состояния
, которые вы встретите в ответном сообщении, поступающем со стороны сервера.
Еще один момент, о котором я упомянул, - это тот факт, что сервер может кодировать данные
в определенном формате, таком как XML или расширяемый язык разметки или JSON, JavaScript
Object Notation для этого.
Теперь, как правило, в этом конкретном курсе мы будем иметь дело с данными
, которые закодированы в основном в JSON.
Большинство приложений, клиентских приложений, включая мобильные приложения в наши дни,
обычно связываются с сервером
и формат обмена данными по умолчанию JSON.
Именно поэтому я потрачу несколько минут на объяснение вам о JSON.
Обозначение объекта javascript, или JSON, представляет собой легкий формат обмена данными.
Причина, по которой формат данных JSON представляет особый интерес для нас в этом курсе, -
, потому что нотация объекта javascript, как следует из названия,
очень легко сопоставляется с объектом javascript, который вы используете с любым из кодов javascript.
Таким образом, преобразование объекта javascript в нотацию JSON,
и наоборот, очень просто.
Эта нотация JSON является, то, что мы называем,
как самоописывающая и очень простая для понимания нотация.
В формате нотации объектов javascript
данные структурированы в очень чистом указанном порядке.
Это структурировано как набор пар имя/значение,
и это структурировано как упорядоченный список значений.
Вы можете увидеть пример этого на правой стороне здесь,
мы фактически использовали данные JSON с нашим угловым приложением уже раньше.
Итак, теперь вы видите, почему данные структурированы таким образом.
И вы также понимаете, что очень легко иметь дело с этими данными
в вашем javascript аудио, машинопись поймается в вашем угловом приложении.
С этим я завершаю краткий обзор основных элементов сети.
Теперь мы перейдем к и упражнения, где мы создадим рудиментарный сервер
, который обслуживал некоторые данные, к которым мы можем подключиться из нашего углового приложения
, а затем обмениваться данными с сервером.
Теперь мы разработаем полноценный сервер в одном из последующих курсов
код узла JS и курс разработки на стороне сервера
, который придет в качестве последнего курса в этой специализации.