Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-21

1 Когда вы заходите на сайт, браузер отправляет запрос на сервер, получает от него ответ и выводит нужную страницу. Но у всех сайтов - разные серверы, информация на которых хранится по-разному.

2 Чтобы браузер понимал, что именно ему нужно запросить, а сервер - что ответить, используют API, или программные интерфейсы приложений. Если вы не знаете или не помните, что это такое и что такое архитектурные стили вообще, рекомендуем сначала прочитать<a>эту статью</a>.

3 API могут быть разными. Самый востребованный из них - REST. О нём и пойдёт речь в этой статье.

4 REST API- это архитектурный подход, который устанавливает ограничения для API: как они должны быть устроены и какие функции поддерживать. Это позволяет стандартизировать работу программных интерфейсов, сделать их более удобными и производительными.

5 Слово REST - акроним от Representational State Transfer, что переводится на русский как "передача состояния представления", "передача репрезентативного состояния" или "передача "самоописываемого“ состояния".

6 В отличие от, например, SOAP API, REST API - не протокол, а простой список рекомендаций, которым можно следовать или не следовать. Поэтому у него нет собственных методов. С другой стороны, его автор Рой Филдинг создал ещё и <a>протокол HTTP</a>, так что они очень хорошо сочетаются, и REST обычно используют в связке с HTTP. Хотя новичкам нужно помнить:REST - это не только HTTP, а HTTP - не только REST.

7 Иногда, помимо акронима REST, можно встретить словоRESTful. Это не термин, но в сообществе его применяют к веб-сервисам, которые соответствуют REST-архитектуре. RESTful используют как прилагательное.

8 Всего в REST есть шесть требований к проектированию API. Пять из них обязательные, одно - опциональное:

9 <ul><li>Клиент-серверная модель (client-server model).</li>

10 <li>Отсутствие состояния (statelessness).</li>

11 <li>Кэширование (cacheability).</li>

12 <li>Единообразие интерфейса (uniform interface).</li>

13 <li>Многоуровневая система (layered system).</li>

14 <li>Код по требованию (code on demand) - необязательно.</li>

15 </ul>Чтобы разобраться в них подробнее, нужно понимать, что в вебе называют ресурсами.Ресурсы - это любые данные: текст, изображение, видео, аудио, целая программа. Например,<a>HTML веб-страницы</a>, на которой вы сейчас находитесь, - тоже ресурс.

16 Это требование отделяет друг от друга два понятия: клиент и сервер.

17 Сервер- программа, в которой хранятся и обрабатываются ресурсы. Сервер может располагаться на одном или нескольких компьютерах; но даже в одном компьютере может быть несколько виртуальных серверов. Допустим, изначально HTML-код этой статьи хранился где-то на серверах Skillbox.

18 Клиент- программа, которая запрашивает у сервера доступ к ресурсам. Для этого она использует API. Когда ваш браузер запрашивает у сервера Skillbox эту веб-страницу, он выступает в роли клиента.

19 Получается структура, при которой клиент направляет к серверу запрос, а в ответ получает ресурсы. Такое разделение позволяет создавать клиент и сервер независимо друг от друга, что ускоряет и упрощает разработку.

20 Изображение: Майя Мальгина для Skillbox MediaПредставим, что вы делаете сервис для учёта деловых переписок. Сами переписки хранятся на сервере, а доступ к ним можно получить из мобильного приложения. Оно не будет хранить никаких данных - только отправлять запросы на сервер, получать ответы и отображать их на экране смартфона.

21 Если вы когда-нибудь захотите полностью изменить логику работы сервера, то это никак не отразится на мобильном приложении. До тех пор, пока они понимают запросы и ответы друг друга, конечно.

22 А чтобы дать доступ к сервису из десктопного приложения и личного сайта, достаточно написать два новых клиента - а на сервере ничего менять не надо. Такая вот гибкость.

23 Изображение: Майя Мальгина для Skillbox MediaВторой принцип настолько важен, что даже отражён в названии архитектурного стиля -Representational State Transfer. Это значит, что на сервере не хранится никаких данных о прошлых взаимодействиях с клиентом - каждый запрос должен содержать всю информацию для его обработки.

24 Например, кто-то запросил последнее сообщение от ООО "Рога и копыта". В этом запросе содержится вся информация, которая нужна серверу, чтобы дать корректный ответ.

25 Если клиент потом хочет получить предпоследнее сообщение, то он не может просто сказать: "Дай мне соседний ресурс" - ему нужно заново составить полный запрос по всем правилам.

26 Это снижает нагрузку на сервер, что особенно полезно, если к нему подключено одновременно много клиентов. Не нужно хранить дополнительную информацию о прошлых обращениях каждого из них. Достаточно обработать каждый запрос в отдельности.

27 Даже если какой-то из предыдущих запросов потеряется, это не сломает логику взаимодействия клиента и сервера, потому что каждый запрос самодостаточен.

28 Иногда клиент запрашивает с сервера одни и те же данные по несколько раз - например, вы постоянно обращаетесь к какому-нибудь важному письму в сервисе для учёта деловых переписок.

29 Если при каждом таком запросе сервер будет с нуля собирать нужные данные и отправлять их клиенту, нагрузка на систему повысится - особенно когда таких повторов много. Решением проблемы в REST API сталокэширование, то есть сохранение части данных у клиента или на промежуточных серверах.

30 Однако тут тоже важно подойти к делу без излишнего фанатизма и не кэшировать всю информацию подряд. Во-первых, для этого потребовались бы слишком большие объёмы памяти. Во-вторых, какие-то данные (скажем, количество исходящих писем) со временем могут устаревать - зачем же держать этот неактуальный хлам в кэше? Именно поэтому в каждом ответе сервера на запрос есть пометка о том, можно ли его кэшировать.

31 Должен бытьединый способ обращенияк каждому ресурсу. Например, мы хотим добавить в наш сервис новую функциональность для просмотра данных о денежных переводах. Понятно, что логика интерфейса для обращения к ним должна быть такой же, как и для всего, что было в сервисе раньше.

32 Файлы обычно передаются клиенту не в том виде, в котором хранятся на сервере. В вебе их часто преобразуют в JSON или XML и только потом отправляют клиенту. Ответ на запросы к новому ресурсу должен приходить в том же формате, что и к старым, и сразу же содержать дополнительную информацию: что разрешается делать с ресурсом, можно ли его изменять и удалять на сервере и так далее.

33 Для реализации единообразного интерфейса в REST API используется принципHATEOAS(Hypermedia as the Engine of Application State).

34 До сих пор мы рассматривали сервер как единую сущность. Но его структура куда сложнее. Между ним и клиентом есть несколько промежуточных узлов, выполняющих вспомогательные функции, -прокси-серверы.

35 Они используются для кэширования, обеспечения безопасности, дополнительной обработки данных. Если основных серверов несколько, то дополнительные серверы-балансировщики могут распределять нагрузку между ними и решать, в какой из них направлять запрос:

36 Изображение: Майя Мальгина для Skillbox MediaНикто из участников цепочки не знает всего пути, который проходит запрос, - только своих "соседей" справа и слева. Ни клиент, ни один из прокси-серверов не знает, к кому он обращается - к основному сервису или к другому прокси. В REST API это работает в обе стороны: никакие серверы (ни основные, ни прокси) не знают, кому отправляют ответ и уходит ли он куда-то дальше.

37 Этот принцип означает, что сервер в ответ на запрос можетотправить исходный код, который выполняется уже на стороне клиента. Благодаря этому можно передавать целые сценарии. Например, динамические элементы пользовательского интерфейса, написанные на JavaScript.

38 В REST API требование необязательно, потому что не всем сайтам и сервисам нужно умение работать с готовыми скриптами.

39 Так как REST - архитектурный подход, а не протокол, в нём не заложено никаких конкретных методов. Но чаще всего его применяют вместе со стандартомHTTP, в котором заложены собственные методы.

40 Если кратко, то в HTTP прописан набор действий, который можно описать аббревиатуройCRUD: create - "создать", read - "прочитать", update - "обновить", delete - "удалить".

41 Для каждого такого действия существуют один или несколько глаголов - это и есть методы. Например, GET для чтения, а PUT и PATCH - для разных видов обновления. Глагол-метод применяется к URL-адресу нужного ресурса, который в "предложении" выполняет роль существительного.

42 Подробнее о работе протокола HTTP и его методов вы можете прочесть в <a>нашей статье</a>.

43 Архитектурный стиль REST - самый распространённый подход к проектированию API. Вот в каких случаях его применяют:

44 <ul><li>пропускная способность соединения с сервером ограничена;</li>

45 <li>нужно соединить мобильные приложения с серверными;</li>

46 <li>проект разбит на микросервисы;</li>

47 <li>сервис предоставляет свои возможности другим разработчикам;</li>

48 <li>используется AJAX;</li>

49 <li>известно, что систему нужно будет масштабировать.</li>

50 </ul>Как мы видим, REST API не случайно стал таким популярным. Повторим основные его отличия:

51 <ul><li>REST - это архитектурный стиль API.Он не ограничивается никакими протоколами и не имеет собственных методов. Но обычно в RESTful-сервисах используют стандарт HTTP, а файлы передают в формате JSON или XML.</li>

52 <li>Естьшесть принципов, на которых строится REST: клиент-серверная модель, отсутствие состояния, кэширование, единообразие интерфейса, многоуровневая система, код по требованию. Последний из них необязателен.</li>

53 <li>REST-подход к архитектурепозволяет сделать сервисы отказоустойчивыми, гибкими и производительными, а при их масштабировании и внесении изменений не возникает больших сложностей.</li>

54 </ul>