Позвольте мне дать вам небольшой отдых. Взял тебя туда.
Я хотел сказать, что позвольте мне дать вам
краткий обзор репрезентативной передачи государства.
Что именно такое REST?
Как мы используем его в нашем приложении React,
и как мы используем это для связи с сервером?
Как сервер поддерживает REST API
и как мы получаем доступ к REST API из нашего приложения React?
Давайте поговорим об этом немного больше в этом уроке.
Я уверен, что вы слышали, как термин веб-сервисы упоминается в мире ИТ очень часто.
Что такое веб-сервисы?
Веб-сервисы - это способ проектирования систем для поддержки взаимодействия
между системами, которые подключены через сеть, как Интернет, как мы видим сегодня.
Это то, что мы называем сервисно-ориентированной архитектурой.
Теперь это означает, что вы предоставляете
стандартизированный способ для двух компьютеров, подключенных к Интернету, чтобы иметь возможность
общаться друг с другом
на уровне приложений для веб-приложений с использованием открытых стандартов.
Я использовал там много жаргона.
Давайте попробуем сломать их и
немного разобраться в каждой из них в этой лекции.
Два общих подхода, которые используются для поддержки веб-сервисов, являются SOAP.
Веб-службы на основе протокола простого доступа к объектам,
использующие язык описания веб-служб для
указания способа взаимодействия между двумя конечными точками.
Как правило, SOAP основан на использовании XML
в качестве формата сообщений, обмениваемых между двумя конечными точками.
Representational State Transfer или REST также использует веб-стандарты,
но обмен данными между двумя конечными точками может быть либо XML, либо
все чаще использовать JSON в качестве формата.
Способ совместимости REST проще по сравнению с SOAP, и, следовательно,
REST нашел гораздо более широкое развертывание в мире веб-сервисов.
Как правило, взаимодействие между клиентом и сервером
упрощается с помощью REST, где сервер поддерживает REST API, и
клиент может затем вызвать конечные точки REST API
для получения информации или загрузки информации на сервер.
Опять же, я упомянул слово, вызывающее конечные точки REST API,
поэтому это несколько терминов, которые я использовал.
Давайте уточним некоторые из них в следующих нескольких слайдах.
Representational State Transfer
— это стиль архитектуры программного обеспечения, который специально разработан для распределенных гипермедиа по всемирной паутине.
Теперь это было впервые представлено Рой Филдингом в его кандидатской диссертации.
Сейчас это одна из тех докторских диссертаций
, которые на самом деле произвели что-то полезное для мира.
Таким образом, это снова нашло много тяги в мире веб-сервисов.
Это набор сетевых принципов, которые определяют, как
ресурсы могут быть доступны на серверах,
и эти ресурсы могут быть доступны от клиентов
путем идентификации ресурсов с помощью конечных точек API отдыха.
В представительском государственном
трансферте есть четыре основных принципа проектирования.
Прежде всего, REST построен на HTTP протоколе,
поэтому он использует все методы HTTP, которые мы уже видели в предыдущем уроке.
Во-вторых, REST предназначен для безгражданства,
что означает, что сервер не хранит никакой информации
о состоянии после завершения связи.
Поэтому, когда сервер получает запрос, сервер отвечает,
а затем он не помнит
ничего больше о разговоре между клиентом и сервером.
В-третьих, способ REST предоставления ресурсов заключается в
раскрытии структуры каталогов, такой как URL-адреса (Uniform Resource Locators - URL).
В-четвертых, формат для обмена данными обычно является JSON
или XML или оба могут поддерживаться с помощью REST.
Одна из мотивов для Рой, предлагающая REST как способ поддержки веб-сервисов, заключается в
том, что он захватывает все вещи, которые хороши
в всемирной паутине, и что сделало Всемирную паутину успешной.
Использование Единых индикаторов ресурсов или
Единых локаторов ресурсов (URL), которые позволяют
обращаться к ресурсам, указав их в качестве URL-адреса.
Второй - это протокол, который живет поверх протокола HTTP.
HTTP уже нашел широкое развертывание в Интернете.
В-третьих, цикл ответа запроса, который известен HTTP.
Таким образом, вы отправляете запрос,
сервер получает ваш запрос, обрабатывает запрос,
отправляет ответ на запрос,
и клиент получает ответ,
действует на него и может генерировать дальнейшие запросы.
Таким образом, этот подход цикла ответа запроса очень
хорошо налажен с HTTP и World Wide Web.
Теперь, протокол HTTP, как мы видели ранее,
мы будем использовать все различные глаголы, которые предоставляет HTTP.
в частности, GET,
PUT, POST и DELETE для
указания операций, которые будут выполняться с ресурсами, хранящимися на стороне сервера.
Так, например, если вы выполняете HTTP-запрос GET,
вы просите сервер вернуть ресурс.
Если вы выполняете запрос POST,
вы запрашиваете сервер для создания нового ресурса.
Если вы выполняете запрос PUT,
вы запрашиваете сервер для обновления существующего ресурса.
И если вы выдаете запрос DELETE,
вы просите сервер удалить ресурс
, идентифицированный конкретным URL-адресом.
Кроме того, он пытается сохранить Idempotence.
Некоторые операции, когда они выполняются даже многократно,
не вызовут никакого изменения состояния.
Некоторые другие операции, если вы выполняете их последовательно,
они могут привести к изменению состояния.
Поэтому вам нужно быть осторожным в отношении того, какие операции могут быть повторены без
каких-либо вредных последствий, и которые должны быть очень тщательно выполнены.
В мире REST вы часто слышите, как люди говорят о существительных, глаголах и представлениях.
Теперь мы уточним каждый из них чуть более подробно в следующих нескольких слайдах.
Существительные конкретно относятся к ресурсам, и эти ресурсы
обычно идентифицируются по их URL-адресам, и они не ограничены.
Глаголы являются ограничением, и они определяют действия, которые должны быть
выполнены на ресурсах и представлениях, как мы видим.
Когда информация должна быть
передана с сервера клиенту или от клиента к серверу,
как вы кодируете информацию.
Как правило, либо с использованием JSON, либо с использованием XML.
Ресурс - это ключевая абстракция, вокруг которой работает REST.
Таким образом, информация абстрагируется в виде ресурса и ресурс
идентифицируется путем указания его с помощью URL.
Таким образом, любая информация, которая может быть инкапсулирована и доступна,
может быть идентифицирована как ресурс.
Часть информации, как текущая погода в Гонконге, может быть ресурсом,
изображение может быть
ресурсом, информация о ценах акций может быть ресурсом и так далее.
Таким образом, все, что вы определяете как часть информации, которая может быть интересна клиенту,
может быть идентифицирована как ресурс.
Вы даже можете иметь дело с ресурсами как с коллекцией
ресурсов, которые сервер может отправить клиенту.
Пример того, как вы называете ресурсы, приведен здесь.
Поэтому мы используем URI для идентификации источника.
Быстрое чтение этих спецификаций или URI здесь
легко позволит вам понять, что мы имеем в виду, используя эти URI.
Так, например, что-то, что заканчивается посудом/,
вы автоматически предполагаете, что это относится к коллекции блюд.
Но тарелки/123, например,
может означать блюдо номер 123 в этом случае и так далее.
Таким образом, это очень легко сохранить, и вы можете указать
коллекцию ресурсов и иметь возможность идентифицировать
их как коллекцию, а затем загрузить их как коллекцию, или вы можете
определить отдельный ресурс и сказать, что вы хотите этот конкретный ресурс.
Теперь эти ресурсы могут быть организованы в иерархию спецификации этого URI.
Таким образом, когда вы пересекаете путь,
вы переходите от более общего к более конкретному ресурсу.
Эта структура каталогов позволяет
легко идентифицировать ресурсы, которые вы используете или предоставляете на стороне сервера.
Вторая часть REST API - это глаголы.
В частности, нас интересуют четыре глагола HTTP GET, PUT
, POST и DELETE.
В этом случае эти глаголы будут сопоставлены в действия, которые мы
хотим выполнить на ресурсе, на стороне сервера.
GET означает, что вы хотите выполнить операцию чтения на ресурсе.
Таким образом, это означает, что клиент, отправляющий запрос GET, указывает серверу,
что он хочет получить представление этого ресурса с серверной стороны на стороне клиента.
POST означает, что вы хотите создать
новый ресурс, а затем вы будете указывать сведения о ресурсе
в представлении, которое используется для
указания ресурса, а затем отправить эту информацию на стороне сервера,
чтобы сервер создавал этот ресурс от вашего имени.
PUT будет модификацией ресурсов и
DELETE, как вы ожидали, это удаление ресурсов.
Таким образом, как вы можете видеть, четыре глагола:
GET, POST, PUT и DELETE,
сопоставляются в четыре операции CRUD, которые вы можете
выполнять в базе данных, которая хранит эти ресурсы на стороне сервера,
операции READ, CREATE, UPDATE и DELETE.
Далее, HTTP GET является способом указания, что вы
хотите,
чтобы информация или представление ресурса были возвращены клиенту со стороны сервера.
Таким образом, когда вы выдаете запрос GET
для конечной точки REST API, вы запрашиваете либо коллекцию ресурсов, представленных
URI, либо конкретный ресурс, который идентифицируется идентификатором этого конкретного ресурса,
указанного в URL-адресе.
Итак, как вы видите в этом примере,
если вы говорите, тарелки/452,
вы имеете в виду, что блюдо номер 452 с
идентификатором 452 должно быть возвращено на стороне клиента.
Аналогично, операция POST, как мы видели, используется для создания ресурса.
Таким образом, при создании ресурса
содержимое описания ресурса будет в виде представления JSON или
XML-представления и будет включено
в тело сообщения запроса, отправляемого на сторону сервера.
Таким образом, операция POST ожидает представление
ресурса в формате JSON или XML в теле сообщения запроса.
Когда сервер получает это сообщение запроса,
сервер создает этот ресурс на стороне сервера, а затем возвращает
либо конформацию, либо ошибку, указывающую на сбой создания ресурса.
Аналогично, операция PUT используется для обновления ресурса.
Когда вы выполняете операцию PUT на ресурсе на стороне сервера,
вы можете отправить изменение,
либо указав только частичное изменение, которое вы хотите воздействовать на
конкретный ресурс в теле ответного сообщения, либо вы можете отправить
полное представление в теле сообщения.
В зависимости от договоренности между клиентом и сервером
сервер ожидает, что информация будет передана в теле сообщения запроса.
Операция DELETE, как вы ожидали, удаляет существующий ресурс.
Теперь, в этом конкретном случае,
конечно, операция DELETE будет идемпотентной, потому что если вы
попытаетесь удалить ресурс и ресурс существует, он будет удален.
Если вы пытаетесь удалить несуществующий ресурс,
это не приведет к дальнейшим изменениям на стороне сервера,
за исключением того, что сервер ответит с ошибкой, говорящей, что ресурс не существует.
Но, тем не менее, DELETE является примером идемпотентной операции в этом случае.
Аналогично, операция GET также является идемпотентной операцией, потому что она
не вносит никаких изменений в ресурс на стороне сервера.
POST и PUT, конечно, собираются изменить ресурс на стороне сервера,
либо создать новый ресурс, либо изменить существующий ресурс на стороне сервера.
Конечно, представления,
как я подчеркивал,
два общих формата для представления - это JSON или XML.
Последняя часть, которую мы должны подчеркнуть, заключается в том,
что серверная сторона должна быть полностью без гражданства, а
это означает, что серверная сторона не отслеживает
состояние клиента, потому что если сервер должен отслеживать состояние клиентов,
он не будет масштабируемым.
Таким образом, для масштабируемой реализации серверной части
вы обычно используете сервер без гражданства на стороне сервера.
Таким образом, каждый запрос, который клиент отправляет на сервер, будет
рассматриваться как независимый запрос и
не будет отражать предыдущие запросы
, которые уже были обработаны сервером от этого конкретного клиента.
Таким образом, клиент несет ответственность за отслеживание своего состояния,
либо в форме использования файлов cookie, либо с помощью клиентской базы данных,
независимо от того, какие средства подходят.
Теперь этот подход, когда клиент отслеживает свое собственное состояние,
намного более масштабируемым, потому что каждый отдельный клиент
будет отвечать за отслеживание своего собственного состояния.
Именно здесь клиентская настройка MVC помогает нам в этом отношении.
Наконец, мы еще не закончили с REST.
Мы увидим больше REST в упражнениях, которые следуют в этом конкретном уроке,
а затем мы также увидим более подробную информацию об использовании REST в остальной части этого курса.