[МУЗЫКА]
Позвольте мне немного отдохнуть.
Я тебя там!
То, что я хотел сказать, было,
позвольте мне дать вам краткий обзор репрезентативного государственного перевода.
Что именно такое отдых?
Как мы используем его в нашем угловом приложении и
, как мы используем это для связи с сервером?
Как сервер поддерживает REST API и
, как мы получаем доступ к REST API из нашего углового приложения?
Давайте поговорим об этом немного больше в этом уроке.
В этой конкретной лекции я дам вам краткий обзор REST.
Я уверен, что вы слышали термин Web Services упоминается
в мире ИТ очень часто.
Что такое веб-сервисы?
Веб-сервисы — это способ проектирования систем для поддержки взаимодействия между
системами, которые подключены по сети, как Интернет, как мы видим сегодня.
Это то, что мы называем сервис-ориентированной архитектурой.
Теперь это означает, что вы предоставляете стандартизированный способ для двух компьютеров
, подключенных к Интернету, чтобы иметь возможность общаться друг с другом.
Их уровень макета приложения для приложений баз данных
с использованием открытых стандартов.
Теперь я использовал много жаргона.
Давайте попробуем сломать их и
немного поймем о каждом из них в этой лекции.
Два распространенных подхода, которые используются для поддержки веб-сервисов, являются SOAP,
простые веб-сервисы на основе протокола доступа к объектам,
, который использует язык описания веб-сервисов для
, определяя, как две конечные точки взаимодействуют друг с другом.
И обычно мыло основано на использовании XML в качестве
формата для обмена сообщениями между двумя конечными точками.
Передача или остальное состояние презентации также использует веб-стандарты, но обмен
данных между двумя конечными точками может быть либо XML, либо все чаще.
Использование JSON в качестве формата.
Способ взаимодействия REST проще по сравнению с SOAP и
, поэтому REST нашел гораздо более широкое развертывание в оставшихся веб-сервисах.
Как правило, взаимодействие с клиентским сервером облегчается с помощью REST
, где сервер поддерживает REST API и клиент может затем вызывать свои конечные точки REST API
для получения информации или загрузки информации на сервер.
Опять же, я упомянул слово, вызываю конечную точку REST API.
Итак, это несколько терминов, которые я использовал.
Давайте проясним некоторые из них в следующих нескольких слайдах.
Перенос репрезентативного состояния — это стиль архитектуры программного обеспечения, который
специально разработан для распределенных гипермедиа через World Wide Web.
Теперь это было впервые представлено Рой Филдингом в его кандидатской диссертации.
Теперь, это одна из тех кандидатских диссертаций, которые фактически произвели
что-то полезное для мира.
Таким образом, это снова нашло много тяги в мире веб-сервисов.
Это набор сетевых принципов, которые описывают, как ресурсы могут быть доступны на серверах, и к этим ресурсам можно получить доступ от клиентов
путем идентификации ресурсов с помощью конечных точек API REST.
В рамках представительного государственного трансферта существует четыре основных принципа проектирования.
Прежде всего, REST основан на протоколе HTTP.
Таким образом, он использует все методы HTTP, которые мы уже видели в предыдущем уроке.
Во-вторых, REST предназначен для безгражданства, что означает, что сервер не хранит
никакой информации о состоянии после завершения связи.
Поэтому, когда сервер получает запрос, сервер отвечает, а затем
после этого, он ничего не помнит об этом
разговоре между клиентом и сервером.
В-третьих, способ REST предоставления ресурсов состоит в том, чтобы
выставить структуру каталогов, такую как URL-адреса однородных локаторов ресурсов.
И в-четвертых, их формат для обмена данными обычно JSON или
XML, или оба они могут поддерживаться с помощью REST.
Одна из мотиваций для подъема, предлагающая REST как способ поддержки веб-сервисов
, заключается в том, что он захватывает все, что хорошо от всей Всемирной паутины.
И это сделало Word Wide Web успешным.
Использование Uniform Resource Indicators или Uniform Resource Locators, URLs,
, которые позволяют обращаться к ресурсам, указав их в качестве URL,
второй протокол, который находится поверх протокола HTTP.
HTTP уже нашел широкое развертывание в Интернете.
В-третьих, цикл ответа на запрос, которым хорошо известен HTTP.
Таким образом, вы отправляете запрос, сервер получает ваш запрос, обрабатывает запрос,
отправляет ответ на запрос, и клиент получает ответ,
действует на это и может генерировать дальнейшие запросы.
Таким образом, этот подход цикла ответа на запрос очень хорошо установлен с HTTP
и всемирным протоколом Web THe HTTP, как мы видели ранее,
мы будем использовать все различные глаголы, которые предоставляет HTTP.
В частности, ворота положить пост удалить.
Для того, чтобы указать операции, которые должны быть выполнены
на ресурсах, хранящихся на стороне сервера.
Так, например, если вы выполняете запрос HTTP GET, вы запрашиваете
сервер для возврата источника.
Если вы выполняете запрос POST, вы запрашиваете сервер для создания нового ресурса.
Если вы выполняете запрос PUT, вы просите сервер обновить
существующий ресурс, и если вы выдаете запрос на удаление, вы просите
сервер удалить ресурс, идентифицированный по этому конкретному URL-адресу.
Также он пытается сохранить идемпотенцию.
Некоторые операции при их выполнении
Даже многократно не вызовут изменения состояния.
Некоторые другие операции, если вы выполняете их последовательно,
они могут привести к изменению состояния.
Поэтому нужно быть осторожным в том, какие операции могут быть повторены без
каких-либо повреждающих последствий.
И которые нужно сделать очень осторожно.
В мире REST вы часто слышите, как люди говорят об существительных,
глаголах и представлениях.
Теперь мы проясним каждый из них немного более подробно в следующих нескольких слайдах.
Существительные, в частности, полны ресурсов и
эти ресурсы обычно идентифицируются по их URL-адресам, и они не ограничены.
Глаголы ограничены, и эти указанные действия должны быть выполнены на ресурсах.
И презентации, как мы видим, когда информация должна быть передана от
сервера клиенту или
от клиента к серверу, как вы кодируете информацию.
Обычно либо с использованием JSON, либо с использованием XML.
Ресурс - это ключевая абстракция, которая работает REST, поэтому
, что информация абстрагируется в ресурсе.
И ресурс идентифицируется, указав его с помощью URI.
Таким образом, любая информация, которая может быть инкапсулирована и
быть доступна, может быть идентифицирована как ресурс.
Часть информации, подобная текущей погоде в Гонконге, может быть ресурсом,
изображение может быть ресурсом.
Информация о ценах акций может быть ресурсом и так далее.
Таким образом, что бы вы ни определяли как часть информации, которую клиент может заинтересовать
, можно идентифицировать как ресурс.
Вы даже можете иметь дело с ресурсами как с коллекцией ресурсов
, которые этот сервер может отправить этому клиенту.
Пример того, как вы называете ресурсы, показан здесь.
Поэтому мы используем URI для идентификации источника.
Быстрое чтение спецификации или URL здесь позволит
легко понять, что мы имеем в виду, используя эти URL-адреса.
Так, например, что-то, что заканчивается на блюде/,
вы автоматически предполагаете, что это относится к коллекции блюд.
Как и посуды/123, например,
может означать блюдо номер 123, в данном случае и так далее.
Так что очень легко сказать, что вы можете указать коллекцию ресурсов, а
сможет идентифицировать их как коллекцию, а затем скачать их как коллекцию.
Или вы можете определить отдельный ресурс, а
сказать, что вы хотите этот конкретный ресурс.
Теперь эти ресурсы могут быть организованы в иерархию
, что спецификация этого URI.
Таким образом, когда вы проходите путь,
вы переходите от более общего к более конкретному из этого ресурса.
Эта структура каталогов позволяет легко идентифицировать ресурсы, которые
вы предоставляете с вашего сайта обслуживания.
Вторая часть REST API - это слова.
В частности, нас интересует 4 глагола HTTP, чтобы получить,
положить, опубликовать и удалить.
В этом случае эти глаголы будут прикасаться к действиям, которые мы
хотим выполнить на ресурсе на стороне сервера.
GETt означает, что вы хотите выполнить операцию чтения на ресурсе, что означает
, что клиент, отправляющий запрос get, указывает серверу, что он хочет
получить представление источника данных с сайта сервера на клиентский сайт.
POST означает, что вы хотите создать новый ресурс, а затем вы будете.
Укажите сведения о ресурсе в представлении, но используется для
указания ресурса.
Затем отправьте информацию на стороне сервера, чтобы
, что сервер создаст ресурс от вашего имени.
PUT будет модификацией ресурсов, а
delete, как вы ожидали, это удаление источников.
Итак, как вы можете видеть четыре глагола получить, пост, поставить и
delete сопоставляются с четырьмя операциями CRUD, которые можно выполнить
в базе данных, хранящей эти ресурсы на стороне сервера.
Операции чтения, создания, обновления и удаления.
Разрабатывая далее, HTTP GET - это способ указания.
Что вы хотите, чтобы информация или их представление ресурса были
возвращены клиенту с сайта сервера.
Поэтому, когда вы выдаете запрос GET конечной точке API REST.
Вы запрашиваете либо коллекцию ресурсов, которые представлены
Uri или конкретный ресурс, который идентифицируется идентификатором
, что конкретные ресурсы, указанные в URL, так как вы видите в этом примере,
, если вы блюдите/452, вы имеете в виду сказать, что блюдо номер 452,
с идентификатором 452 должны быть возвращены на клиентскую сторону.
Аналогично, почтовая операция, как мы видели, используется для создания ресурса.
Таким образом, когда вы создаете ресурс, содержание описания ресурса будет
в виде представления JSON или XML-представления, и это будет
включено в тело сообщения запроса, которое отправляется на стороне сервера.
Таким образом, после операции ожидает представление
ресурса в формате JSON или XML в теле сообщения запроса.
И сервер получает такое сообщение запроса, сервер создает этот ресурс
на стороне сервера, а затем возвращает либо подтверждение, либо
ошибку, указывающую на то, что создание ресурса не удалось.
Точно так же он поставил операцию легко использовать для обновления ресурса.
Когда вы выполняете операцию PUT на ресурсе на стороне сервера, вы можете отправить обратно
модификацию либо указав только частичное изменение
, которое вы хотите воздействовать на конкретный ресурс в теле ответного сообщения.
Или вы можете отправить полное представление ресурса
в теле сообщения, в зависимости от расположения клиента и
сервера, сервер ожидает, что информация будет
передана в теле сообщения запроса.
DELETE операция, как вы ожидаете, удаляет существующий ресурс.
Теперь в данном конкретном случае, конечно, операция удаления будет заключаться в том, что
, если вы попытаетесь удалить ресурс и ресурс существует, он будет удален.
Если вы пытаетесь удалить несуществующий ресурс,
это не приведет к дальнейшим изменениям на стороне сервера, кроме
, что сервер ответит с ошибкой, говорящим, что ресурс не существует.
Но тем не менее, является примером операции в данном случае.
Аналогично, операция get также будет работать, потому что она не делает
никаких изменений в ресурс на сайте сервера.
Ввод сообщений, конечно, будет изменять ресурс на стороне сервера.
Вам нужно создать новый ресурс или
изменить существующий ресурс на стороне сервера и, конечно же, презентации данных.
Как я подчеркивал, две общие резервные копии для
представляют собой либо JSON XML, последняя часть
, которую мы должны подчеркнуть, заключается в том, что серверная сторона должна быть полностью без гражданства.
Это означает, что серверная сторона не отслеживает состояние клиента.
Потому что, если сервер должен отслеживать состояние клиента, он не будет масштабироваться.
Таким образом, для масштабируемой реализации серверной стороны
вы обычно используете сервер без состояния на стороне сервера.
Таким образом, если запрос клиентов, отправленный на сервер, будет рассматриваться как
независимый запрос и не будет отражать предыдущие
запросы, которые уже были обработаны сервером от конкретного клиента.
Таким образом, клиент несет ответственность за отслеживание своего собственного состояния.
Либо в виде использования файлов cookie, либо с использованием базы данных клиентского сайта.
Что бы то ни было значит, что это подходит.
Теперь этот подход, когда клиент отслеживает свое собственное состояние, намного более масштабируемый,
, потому что ваш клиент будет отвечать за отслеживание своего собственного.
И вот где настройка MVC на стороне клиента помогает нам в этом отношении.
И, наконец, мы еще не закончили с REST, мы увидим больше
REST в упражнениях, которые следуют в этом конкретном уроке.
А затем,
, мы увидим более подробную информацию об использовании REST в остальной части этого курса.
[МУЗЫКА]