Разбор платного курса Практикума по бэкенду: модуль про API

Сегодня — разбор очередного блока из полного курса Практикума по бэкенду: API: интерфейс взаимодействия программ. Как обычно, с множеством скриншотов, пояснений и рассказом о том, как там всё устроено.

Начало

Вот полная карта нашего путешествия:

Как обычно, в начале каждого блока нас встречает рассказ о спринтах, о том, что будем делать в этой части и над какими проектами будем работать. Практики тут, как и в других разделах, много, поэтому если ждёте только теорию — лучше не ждите, писать код придётся много :)

Что такое API. Форматы обмена данными

API — это аббревиатура от английского Application Programming Interface, интерфейс программирования приложения. Чтобы было понятнее, расшифруем так:

API — это то, что может делать приложение по просьбе других приложений.

Само по себе приложение, сервис или программа не умеют работать с другими программами — они работают, делают то, что им нужно, и не обращают внимания на внешний мир. Но если программист добавит поддержку API в свою программу, то она научится обрабатывать не только свои данные, но и данные из других приложений.

Так как курс рассчитан на тех, кто приходит в ИТ с нуля, нас подробно погружают в тему, объясняя все сложные и непонятные моменты. Язык довольно простой, поэтому с пониманием проблем возникнуть не должно:

Кроме объяснений и текста, в курсе много схем и картинок, которые иллюстрируют ключевые тезисы. Если что, все термины, которые есть на схемах на английском, в тексте заранее объясняются:

После чистой теории нас начинают знакомить с основными форматами, которыми пользуются программы для обмена данными между собой. Всё начинается с классики — JSON, причём не только в теории, но и в виде кода, который даёт представление о структуре данных:

[
  {
    "name": "Captain America",
    "realName": "Steve Rogers",
    "yearCreated": 1941,
    "powers": [
      "Strength",
      "Healing ability"
   ]
  }
]

Следом за ним — дедушка XML, тоже теория плюс код:

<?xml version="1.0" encoding="UTF-8" ?>
<root>
    <superhero>
        <name>Captain America</name>
        <realName>Steve Rogers</realName>
        <yearCreated>1941</yearCreated>
        <powers>Strength</powers>
        <powers>Healing ability</powers>
    </superhero>
    <superhero>
        <name>Spider-Man</name>
        <realName>Peter Parker</realName>
        <yearCreated>1963</yearCreated>
        <powers>Danger sense</powers>
        <powers>Speed</powers>
        <powers>Jumping</powers>
    </superhero>
</root> 

Как обычно в каждом курсе Практикума, в уроках есть промежуточные вопросы на понимание темы — с объяснениями правильных и неправильных ответов. Они сразу показывают, насколько вы усвоили текущее объяснение и нужно ли вернуться чуть выше и что-то перечитать.

После того как разобрались с классическими форматами, переходим к протоколам обмена данными. Это приближает нас к программистской реальности, когда нужно знать не просто про форматы, но и про то, как с ними работать, передавать, получать и так далее:

Сразу после теории — код для наглядности, чтобы всё вместе сложилось в единую и понятную картинку:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <!--Здесь служебная информация, например данные для авторизации-->
  </soap:Header>

  <soap:Body>
    <!--Здесь тело сообщения, пересылаемые данные-->
    <student>
      <username>Стас Басов</username>
      <faculty>Python</faculty>
    </student>

    <student>
      <username>Jacob Ludwig Karl Grimm</username>
      <faculty>Fable</faculty>
    </student>
  </soap:Body>

  <soap:Fault>
    <!--Здесь может быть список ошибок. Но это не обязательно-->
  </soap:Fault>

</soap:Envelope>

С каждым новым уроком темы становятся глубже и немного сложнее. Это логично: у нас постепенно появляется фундамент, на который мы можем опереться в дальнейшем и строить своё развитие. 

Отдельно стоит отметить картинки, которые иллюстрируют разные способы и приёмы использования разных технологий. Например, нам понравилось сравнение взаимодействия программ с помощью REST и без него (в жизни оно тоже примерно так, да):

Так как это уже не первый блок в курсе, предполагается, что мы сами можем работать с несложным кодом, выполнять его в своей среде разработки без тренажёра и оценивать результат:

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

Так, шаг за шагом, мы изучаем базу по теории — от простых понятий API до токенов, аутентификации и их взаимодействия:

Работа с внешними API

Чтобы обучение проходило живее и интереснее, в курсе моделируются разные жизненные ситуации, с которыми может столкнуться разработчик в настоящих проектах. Например, в этом разделе всё начинается с письма тимлида, который просит нас сделать телеграм-бота. Забегая вперёд, скажем, что к концу блока простой бот превратится в полноценный бэкенд-сервис с приличным функционалом.

Нам подробно объясняют, как создать своего бота, как его зарегистрировать, какие библиотеки в Python нужны для работы с ним и что вообще куда нажимать. Действительно, наглядно и подробно:

Все тонкости и вопросы, которые могут появиться у студентов, тоже разбираются со всей тщательностью, скриншотами и примерами. Скажем, один из самых частых вопросов: как узнать ID другого аккаунта? А вот так:

Как только изучили часть теории — сразу закрепляем её на практике. Вообще, надо быть готовым к тому, что код придётся писать часто и много (и это позволяет получить колоссальный практический опыт и полностью понять всю тему).

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

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

REST API

REST API — самый популярный сегодня вид API. Название образуется от английского REpresentational State Transfer, что можно перевести как «передача самоописываемого состояния». Принципы REST API состоят в том, чтобы использовать стандартные HTTP-запросы:

Это основные операции при работе с данными, они обозначаются аббревиатурой CRUD (create, read, update, delete — создание, чтение, обновление и удаление).

В новом блоке нам шаг за шагом объясняют все возможности этой технологии и работы с ней — как в целом, так и в разрезе текущего проекта, который мы делаем в этом блоке:

Так как мы делаем полноценный проект, то нам нужно научиться тестировать все новые технологии, которые мы будем использовать. Это пригодится и сейчас, и в будущем, когда появятся новые задачи и нам нужно будет убедиться, что всё работает так, как задумано:

Объяснения максимально подробные, со схемами и пояснениями, что, где и как происходит во время тестирования:

Как только изучили что-то новое, идём практиковаться в тренажёр. Обратите внимание на дерево файлов слева: мы начинали с одного файла, а теперь постепенно в проект добавились и остальные (которые мы сами и написали по ходу этого раздела):

Кроме этого, нам объясняют разные способы работы с API и авторизацией, как простые, так и сложные, чтобы проект был максимально приближен к тому, как работают с этой технологией в жизни:

Права, лимиты запросов и фильтрация ответов в DRF

Интересный раздел, сначала поясним на простом примере, что это вообще такое — DRF.

Права (Permissions) в DRF — это как охранники на входе в клуб. Они решают, можно ли конкретному пользователю вообще получить доступ к вашим данным (например, к списку заказов или профилей). Бывают разные уровни доступа: некоторые страницы доступны всем (как меню на сайте), другие — только зарегистрированным пользователям, а самые важные — только администраторам. Права отвечают на вопрос: «Имеет ли этот человек право делать то, что он пытается сделать?» — прежде чем вообще начать обработку его запроса.

Лимиты запросов (Throttling) — это уже не охранник, а швейцар, который следит, чтобы один и тот же посетитель не захламлял всех своими просьбами. Он ограничивает количество запросов, которые пользователь может отправить серверу за определённый промежуток времени (например, не больше 100 в час). Это важно для защиты вашего API от злоумышленников, которые могут попытаться его «положить» тысячами запросов, или от ошибок в коде клиента, которые могут слишком часто вас беспокоить.

Фильтрация ответов (в контексте прав) — это последний этап. Представьте, что пользователь прошёл охранника (права) и швейцара (лимиты) и мы готовы ему что-то показать. Но даже внутри доступной ему информации могут быть детали, которые ему видеть не положено. Например, один пользователь может видеть только свои заказы, а не все заказы в системе, или ему можно показать только имя и почту другого пользователя, но не его пароль. Фильтрация гарантирует, что в ответе будут только те данные, которые разрешено видеть этому конкретному пользователю.

Как только разобрались с теорией — сразу к практике, проверять на прочность лимиты и права:

Параллельно с этим нам объясняют, как работать с ответами сервера, что они означают и как понять, что приложение работает правильно:

К этому моменту нас уже не пугают большие задания в тренажёре, где нужно написать много своего кода в разных файлах:

Взаимодействие фронтенда и бэкенда

Взаимодействие фронтенда и бэкенда — это архитектура клиент-серверного приложения, где фронтенд выступает в роли клиента, а бэкенд — сервера. Фронтенд, работающий в браузере (или мобильном приложении), отвечает за рендеринг UI, обработку пользовательских событий и формирование HTTP-запросов. Его ключевая задача — отправить структурированный запрос (например, на создание ресурса через POST /api/articles или получение данных через GET /api/users) и корректно отобразить полученный ответ. Бэкенд, в свою очередь, принимает эти запросы, выполняет валидацию, применяет бизнес-логику, взаимодействует с базой данных и формирует ответ в формате JSON (или ином формате). Он полностью инкапсулирует в себе состояние приложения и данные, предоставляя фронтенду только контракт в виде API.

Коммуникация между ними строится на основе REST API (который мы как раз изучаем), где запросы и ответы следуют строгой договорённости. Фронтенд не имеет прямого доступа к БД и не реализует критичную бизнес-логику — он работает через API, предоставляемое бэкендом. Ответ сервера всегда содержит HTTP-статус, который фронтенд должен корректно интерпретировать, и тело ответа с данными в формате JSON. Для обеспечения безопасности и состояния (например, аутентификации) часто используются механизмы кук (например, сессии) или токены (JWT в заголовке Authorization), которые фронтенд обязан включает в каждый запрос.

Но это лишь начало, а в новом разделе нас знакомят с принципами построения разных архитектур и различиями между ними (по уровню работы клиента и сервера):

Мемы, которые никогда не стареют, тоже на месте:

Что в итоге

Так, шаг за шагом, мы узнаём о том, что такое API в контексте бэкенда и учимся полноценно работать с этой технологией. 

В этом обзоре многое осталось за скобками: и примеры разных тем, которые там разбираются, и задания, которые связаны друг с другом, и промежуточные проекты, которые в итоге соединяются в одно большое и полноценное приложение (с котиками!):

Вывод такой: после этого блока вы научитесь работать с API так, как будто вы сами придумали эту технологию. А написать код, который подружит одну часть сервиса с другой, не составит вообще никаких проблем. Мы проверили и убедились на себе, теперь ваша очередь :-)

Бонус для читателей

Если вам интересно погрузиться в мир ИТ и при этом немного сэкономить, держите наш промокод на курсы Практикума. Он даст вам скидку при оплате, поможет с льготной ипотекой и даст безлимит на маркетплейсах. Ладно, окей, это просто скидка, без остального, но хорошая. 

Вам слово

Приходите к нам в соцсети поделиться своим мнением о курсе и почитать, что пишут другие. А ещё там выходит дополнительный контент, которого нет на сайте — шпаргалки, опросы и разная дурка. В общем, вот тележка, вот ВК — велком!