HTTP and REST API
otus.ru
Проверить, идет ли запись
Меня хорошо видно
&& слышно?
Ставим “+”, если все хорошо
“-”, если есть проблемы
HTTP и REST API
Тема вебинара
Игорь Звягин
Frontend team-lead в leadvertex
Во frontend разработке c 2016 года,
разрабатывал, и интернет магазины, и лендинги, и сложную crm систему
Являюсь заклинателем хуков в 5 поколении, вызываю дождь методами жизненного цикла.
Я на связи в телеграмм spirit_drive
Обмен данными
Обмен данными. Протоколы
Сетевые протоколы передачи данных — набор правил, который определяет порядок и особенности передачи информации для конкретных случаев. Существует множество протоколов, самые популярные
Internet Protocol — IP
IP отвечает за поиск компьютеров в сети по их IP-адресам. Ещё он предоставляет стратегию маршрутизации, то есть составляет оптимальный маршрут для передачи данных.
Данные в интернете передаются IP-пакетами. У каждого пакета есть заголовок и данные. В заголовке находятся IP-адреса источника и пункта назначения. Данные — это само содержимое, например, часть веб-страницы.
Работу IP можно сравнить с почтовым отделением: протокол направляет IP-пакеты по интернету так же, как почта рассылает письма по всему миру. При доставке почта использует пункты передачи: письмо из отделения сначала попадает на поезд, потом на грузовик и в конце вручается адресату. В интернете тоже есть «пункты передачи» — их называют маршрутизаторами. Цель маршрутизатора — отправить пакет в пункт назначения по самому короткому пути. Если всё идёт хорошо, пакет прибывает на ближайший к получателю маршрутизатор, который точно знает, куда его отправить. Но бывает и так, что какой-то из маршрутизаторов на пути взломан или вышел из строя, и тогда выбирается другой путь
DNS
Уникальный IP-адрес есть у каждого домена. Он записывается в виде четырёх чисел от нуля до 255 — например, 74.125.20.113. Введите этот адрес в браузерную строку и посмотрите, на какой сайт вы попали.
DNS связывает IP-адрес с понятным для людей доменным именем.
Принцип работы DNS похож на поиск и вызов контактов в телефоне. Вряд ли кто-то помнит 1317 друзей — да это и необязательно, ведь они хранятся в списке контактов. Когда мы хотим кому-то позвонить, то просто находим нужное имя и нажимаем кнопку вызова — в этот момент начинается соединение, но не по имени, а по номеру телефона.
DNS-сервер — это и есть «список всех контактов», то есть IP-адресов, которые там хранятся. Каждому IP-адресу присвоен домен. И когда мы вводим в строке браузера имя домена, то происходит запрос к DNS-серверу — запрашивается IP-адрес.
TCP и UDP
Оба протокола отвечают за передачу данных и работают поверх IP, но с небольшой разницей. TCP доставляет данные без потерь, поэтому его используют для передачи фотографий, сообщений и другой важной информации. А вот UDP не гарантирует доставку, но зато он гораздо быстрее. Его используют, когда скорость важнее надёжности, например, при передаче аудиосообщений или видеотрансляциях.
FTP — File Transfer Protocol
Протокол передачи файлов. Его использовали ещё в 1971 году — задолго до появления протокола IP. На текущий момент этим протоколом пользуются при удалённом доступе к хостингам. FTP является надёжным протоколом, поэтому гарантирует передачу данных.
Этот протокол работает по принципу клиент-серверной архитектуры. Пользователь проходит аутентификацию (хотя в отдельных случаях может подключаться анонимно) и получает доступ к файловой системе сервера.
SSL/TSL
SSL — криптографический протокол шифрования запросов и ответов, он нужен для безопасного перемещения данных по интернету, а TLS — его продвинутая версия. SSL уже почти не используют, но это название было таким популярным, что его до сих пор употребляют, а любой SSL-сертификат у хостинг-компаний — TLS-сертификат.
NTP — Network Time Protocol
Не все протоколы передачи нужны для обмена классического вида информацией. NTP — протокол для синхронизации локальных часов устройства со временем в сети. Он использует алгоритм Марзулло. Благодаря нему протокол выбирает более точный источник времени. NTP работает поверх UDP — поэтому ему удаётся достигать большой скорости передачи данных. Протокол достаточно устойчив к изменениям задержек в сети.
Последняя версия NTPv4 способна достигать точности 10мс в интернете и до 0,2мс в локальных сетях.
SSH — Secure SHell
Протокол для удалённого управления операционной системой с использованием TCP. В SSH шифруется весь трафик, причём с возможностью выбора алгоритма шифрования. В основном это нужно для передачи паролей и другой важной информации.
Также SSH позволяет обрабатывать любые другие протоколы передачи. Это значит, что кроме удалённого управления компьютером, через протокол можно пропускать любые файлы или даже аудио/видео поток.
SSH часто применяется при работе с хостингами, когда клиент может удалённо подключиться к серверу и работать уже оттуда.
HTTP и HTTPS
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данныx.
HTTP и HTTPS предназначены для передачи данных и в итоге пользователи могут просматривать веб-страницы. На самом деле HTTPS — это не отдельный протокол, а расширение HTTP. Он безопаснее, так как использует SSL/TLS для шифрования обычных запросов и ответов.
HTTP
HTTP — один из самых используемых протоколов в интернете, поэтому посмотрим подробнее, как он работает.
Протокол работает в формате запрос-ответ с двумя участниками общения:
Клиент делает запрос на сервер для передачи каждого ресурса: файлов HTML, CSS, JavaScript, изображений или видеофайлов. Затем сервер отвечает на запрос, отправляя ресурс.
HTTP
Для каждого запроса и ответа открывается своё TCP-соединение. При каждом соединении происходит трёхстороннее «рукопожатие»: клиент и сервер трижды обмениваются пустыми пакетами данных, чтобы удостовериться в существовании друг друга и готовности к работе с данными
HTTP/2
HTTP/2 — улучшенная версия HTTP. По данным Can I Use, его поддерживают большинство браузеров.
Главное нововведение этого протокола — одно TCP-соединение на разные запросы, или мультиплексирование:
HTTP/2
Ещё в HTTP/2 появился push-сервер, то есть сервер может отправлять больше ответов на один клиентский запрос. Например, если клиент запрашивает файлы index.html, style.css и logo.svg, то сервер отправит сразу три файла. Без push-сервера клиенту нужно запрашивать каждый файл отдельно
HTTP/3
HTTP/3 — третья версия HTTP, основанная на QUIC — протоколе, который предполагает быстрое подключение к интернету через UDP.
Главное преимущество HTTP/3 — сокращение задержки при установке соединения. QUIC достаточно одного «рукопожатия», чтобы установить безопасный сеанс. А ещё HTTP/3 работает поверх UDP, поэтому скорость доставки данных быстрее, чем у HTTP и HTTP/2 поверх TCP.
Протокол уже получил статус предложенного стандарта, то есть браузеры почти завершили работу над поддержкой протокола. Но пока поддержки недостаточно, чтобы переводить сайт с HTTP/2 на HTTP/3.
WebSockets
В этом протоколе соединение устанавливается гораздо быстрее, чем в HTTP — здесь отправляется «рукопожатие» сразу со всей необходимой информацией для передачи данных. Канал при этом остаётся открытым, пока кто-то из сторон не прервёт его. Это означает, что запросы и ответы будут происходить практически мгновенно. А если сервер получит новые данные, он отправит их клиенту без запроса
Вопросы?
Ставим “+”,
если вопросы есть
Ставим “–”,
если вопросов нет
HTTP протокол
HTTP протокол
Представляет собой обмен текстовыми файлами, написанными по определенным правилам
Запрос
GET /wiki/HTTP HTTP/1.0
Host: ru.wikipedia.org
Заголовки запроса
Тело запроса (не обязательно) после переноса строки
Ответ
HTTP/1.0 200 OK (не обязательно это)
Заголовки ответа
Тело ответа (не обязательно) после переноса строки
HTTP протокол. Методы
Метод - это ключевое слово перед url запроса.
GET /wiki/HTTP HTTP/1.0
По умолчанию используется GET метод. Часто если нужно изменить состояние сервера, используют POST метод. Список методов длинный, но нет строгих правил, требующих использование того или иного запроса.
HTTP протокол. Методы
HTTP протокол. Статус (Код состояния)
Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трёх цифр[3]. Первая цифра указывает на класс состояния
В настоящее время выделено пять классов кодов состояния
1хх - Информационный
2хх - Успех
3хх - Перенаправление
4хх - Ошибка клиента
5хх - Ошибка сервера
Все общепринятые коды
Вопросы?
Ставим “+”,
если вопросы есть
Ставим “–”,
если вопросов нет
REST api
REST api
REST API — это архитектурный подход, который устанавливает ограничения для API: как они должны быть устроены и какие функции поддерживать. Это позволяет стандартизировать работу программных интерфейсов, сделать их более удобными и производительными.
Слово REST — акроним от Representational State Transfer, что переводится на русский как «передача состояния представления», «передача репрезентативного состояния» или «передача „самоописываемого“ состояния».
В отличие от, например, SOAP API, REST API — не протокол, а простой список рекомендаций, которым можно следовать или не следовать. Поэтому у него нет собственных методов. С другой стороны, его автор Рой Филдинг создал ещё и протокол HTTP, так что они очень хорошо сочетаются, и REST обычно используют в связке с HTTP
REST api
Принципы архитектуры
REST api. Принципы архитектуры
Всего в REST есть шесть требований к проектированию API. Пять из них обязательные, одно — опциональное:
Клиент-серверная модель
Это требование отделяет друг от друга два понятия: клиент и сервер.
Сервер — программа, в которой хранятся и обрабатываются ресурсы. Сервер может располагаться на одном или нескольких компьютерах; но даже в одном компьютере может быть несколько виртуальных серверов.
Клиент — программа, которая запрашивает у сервера доступ к ресурсам. Для этого она использует API. Когда ваш браузер запрашивает у сервера эту веб-страницу, он выступает в роли клиента.
Получается структура, при которой клиент направляет к серверу запрос, а в ответ получает ресурсы. Такое разделение позволяет создавать клиент и сервер независимо друг от друга, что ускоряет и упрощает разработку.
Отсутствие состояния
Второй принцип настолько важен, что даже отражён в названии архитектурного стиля — Representational State Transfer. Это значит, что на сервере не хранится никаких данных о прошлых взаимодействиях с клиентом — каждый запрос должен содержать всю информацию для его обработки.
Например, кто-то запросил последнее сообщение от ООО «Рога и копыта». В этом запросе содержится вся информация, которая нужна серверу, чтобы дать корректный ответ.
Если клиент потом хочет получить предпоследнее сообщение, то он не может просто сказать: «Дай мне соседний ресурс» — ему нужно заново составить полный запрос по всем правилам.
Это снижает нагрузку на сервер, что особенно полезно, если к нему подключено одновременно много клиентов. Не нужно хранить дополнительную информацию о прошлых обращениях каждого из них. Достаточно обработать каждый запрос в отдельности.
Кэширование (и fetch)
Иногда клиент запрашивает с сервера одни и те же данные по несколько раз — например, вы постоянно обращаетесь к какому-нибудь важному письму в сервисе для учёта деловых переписок.
Если при каждом таком запросе сервер будет с нуля собирать нужные данные и отправлять их клиенту, нагрузка на систему повысится — особенно когда таких повторов много. Решением проблемы в REST API стало кэширование, то есть сохранение части данных у клиента или на промежуточных серверах.
Однако тут тоже важно подойти к делу без излишнего фанатизма и не кэшировать всю информацию подряд. Во-первых, для этого потребовались бы слишком большие объёмы памяти. Во-вторых, какие-то данные (скажем, количество исходящих писем) со временем могут устаревать — зачем же держать этот неактуальный хлам в кэше? Именно поэтому в каждом ответе сервера на запрос есть пометка о том, можно ли его кэшировать.
Единообразие интерфейса
Должен быть единый способ обращения к каждому ресурсу. Например, мы хотим добавить в наш сервис новую функциональность для просмотра данных о денежных переводах. Понятно, что логика интерфейса для обращения к ним должна быть такой же, как и для всего, что было в сервисе раньше.
Файлы обычно передаются клиенту не в том виде, в котором хранятся на сервере. В вебе их часто преобразуют в JSON или XML и только потом отправляют клиенту. Ответ на запросы к новому ресурсу должен приходить в том же формате, что и к старым, и сразу же содержать дополнительную информацию: что разрешается делать с ресурсом, можно ли его изменять и удалять на сервере и так далее.
Для реализации единообразного интерфейса в REST API используется принцип HATEOAS (Hypermedia as the Engine of Application State). HATEOAS на хабр
Многоуровневая система
До сих пор мы рассматривали сервер как единую сущность. Но его структура куда сложнее. Между ним и клиентом есть несколько промежуточных узлов, выполняющих вспомогательные функции, — прокси-серверы.
Они используются для кэширования, обеспечения безопасности, дополнительной обработки данных. Если основных серверов несколько, то дополнительные серверы-балансировщики могут распределять нагрузку между ними и решать, в какой из них направлять запрос
Код по требованию (необязательно)
Этот принцип означает, что сервер в ответ на запрос может отправить исходный код, который выполняется уже на стороне клиента. Благодаря этому можно передавать целые сценарии. Например, динамические элементы пользовательского интерфейса, написанные на JavaScript.
В REST API требование необязательно, потому что не всем сайтам и сервисам нужно умение работать с готовыми скриптами.
Вопросы?
Ставим “+”,
если вопросы есть
Ставим “–”,
если вопросов нет
REST api
Методы
Методы REST API
Так как REST — архитектурный подход, а не протокол, в нём не заложено никаких конкретных методов. Но чаще всего его применяют вместе со стандартом HTTP, в котором заложены собственные методы.
Если кратко, то в HTTP прописан набор действий, который можно описать аббревиатурой CRUD: create — «создать», read — «прочитать», update — «обновить», delete — «удалить».
Для каждого такого действия существуют один или несколько глаголов — это и есть методы. Например, GET для чтения, а PUT и PATCH — для разных видов обновления. Глагол-метод применяется к URL-адресу нужного ресурса, который в «предложении» выполняет роль существительного.
HTTP + React
HTTP + React
На сегодняшний день не существует единого решения для отправки запросов в react.
Можно использовать:
Вопросы?
Ставим “+”,
если вопросы есть
Ставим “–”,
если вопросов нет
Рефлексия