search

01 vvedenie api

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

hashtag
1. Что такое API

API (Application Programming Interface) — это интерфейс для программ. Проще говоря, это набор правил и способов, по которым одна программа может попросить другую программу что-то сделать или отдать данные.

hashtag
Аналогия из жизни

Представьте кафе. Вы — клиент (ваше приложение). Официант — это API: вы не заходите на кухню и не готовите сами, вы просто говорите официанту: «Принесите кофе и булку». Он передаёт заказ на кухню (серверу) и приносит результат. Вы не знаете, как именно готовят кофе — вам важно только получить его. Так же и с API: ваша программа не лезет «внутрь» чужого сервера, а просто отправляет запросы по заранее описанным правилам и получает ответы.

hashtag
Зачем нужны API

  • Разделение ответственности — один сервис хранит данные и логику, другие только запрашивают и показывают.

  • Интеграции — приложения обмениваются данными (погода, карты, платёжные системы).

  • Масштабирование — можно делать веб, мобильное приложение и бота к одному и тому же API.

  • Безопасность — доступ к данным контролируется через ключи и права, а не через прямой доступ к базе.

В нашей методичке мы будем учиться работать именно с таким «официантом» — API компании: отправлять запросы, получать ответы и писать код, который с ним общается.

hashtag
2. Как устроена сеть: TCP/IP и HTTP

Чтобы понять, как «доходят» запросы до API, полезно иметь общее представление о том, как устроена сеть.

hashtag
TCP/IP — основа интернета

TCP (Transmission Control Protocol) и IP (Internet Protocol) — это протоколы, на которых держится интернет.

  • IP отвечает за адресацию: у каждого устройства в сети есть IP-адрес (например, 192.168.1.1 или 8.8.8.8). IP «доставляет» пакеты данных от одного адреса к другому.

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

Когда вы открываете сайт или вызываете API, под капотом сначала устанавливается TCP-соединение между вашим компьютером и сервером (по IP-адресу и порту). Без TCP/IP не было бы ни браузера, ни API.

hashtag
HTTP — протокол «запрос–ответ»

HTTP (HyperText Transfer Protocol) — это протокол прикладного уровня. Он определяет, как формулировать запросы и ответы поверх TCP.

  • Клиент (браузер, приложение, скрипт) отправляет HTTP-запрос: метод (GET, POST и т.д.), URL, заголовки, иногда тело (body).

  • Сервер обрабатывает запрос и возвращает HTTP-ответ: код состояния (200, 404, 500…), заголовки и тело (часто JSON или HTML).

Большинство API в интернете работают по HTTP (или его защищённой версии — HTTPS). То есть ваша программа по сути отправляет HTTP-запросы на определённые адреса (URL) и читает HTTP-ответы.

hashtag
3. Безопасность: HTTP и HTTPS, зачем защита данных

При обращении к API по сети данные проходят через провайдера, маршрутизаторы, возможно публичный Wi‑Fi. Без защиты их может перехватить или изменить кто-то посторонний. HTTPS как раз и решает эту задачу: он добавляет к обычному HTTP шифрование и проверку того, что вы общаетесь с нужным сервером.

hashtag
Зачем вообще нужна защита

По HTTP (без буквы S) запросы и ответы передаются в открытом виде — как обычный текст. Любой, кто имеет доступ к трафику (сетевой администратор, владелец точки Wi‑Fi, злоумышленник в той же сети), может:

  • Увидеть содержимое — URL, заголовки, логины и пароли, токены, тело запроса и ответа. Достаточно перехватить пакеты или посмотреть логи прокси.

  • Подменить данные — изменить ответ сервера (например, подсунуть другую страницу или другой JSON), изменить запрос по пути.

  • Притвориться сервером — направить вас на свой сервер вместо настоящего API и собирать ваши данные или показывать фейковый контент.

Для API это особенно критично: в запросах часто передаются токены доступа, персональные данные, платёжная информация. Поэтому пароли, токены и чувствительные данные нельзя отправлять по HTTP — только по HTTPS (или по защищённым каналам внутри изолированной сети, если так предусмотрено политикой безопасности).

hashtag
В чём отличие HTTP и HTTPS

HTTP
HTTPS

Порт

Обычно 80

Обычно 443

Как передаются данные

В открытом виде (plain text). Перехватив трафик, можно прочитать всё: URL, заголовки, тело.

В зашифрованном виде. Перехватчик видит только факт соединения и объём данных, но не содержимое.

Кто на другом конце

Клиент не проверяет. Теоретически ответ может отдать любой, кто перехватил запрос или подменил маршрут.

Клиент проверяет сертификат сервера. Если сертификат выдан доверенным центром и совпадает с доменом — выше уверенность, что это именно тот API, а не подмена.

Изменение данных по пути

Запрос или ответ можно изменить (подмена страницы, поддельный JSON).

При правильной настройке изменение данных нарушает шифрование, и сторона получит ошибку (целостность защищена).

Итог: HTTP подходит только для публичных, нечувствительных данных в контролируемой среде. Для любого API с авторизацией, персональными или платёжными данными нужен HTTPS.

hashtag
Как HTTPS защищает данные (упрощённо)

  1. Согласование и шифрование. При установке соединения клиент и сервер договариваются о параметрах шифрования (протокол TLS/SSL). Дальше весь обмен (запросы и ответы) идёт в зашифрованном виде. Перехвативший трафик без секретного ключа не сможет прочитать содержимое.

  2. Сертификат и проверка сервера. Сервер предъявляет сертификат — документ, в котором указано, какому домену он принадлежит, и который подписан доверенным центром сертификации (или цепочкой таких центров). Браузер и клиентские библиотеки проверяют подпись и домен: если всё совпадает, считают, что общаются с настоящим api.example.com, а не с подставным сервером.

  3. Целостность. Шифрование и механизмы TLS позволяют обнаружить изменение данных в пути. Если кто-то подменит байты в зашифрованном потоке, при расшифровке получится ошибка, и соединение можно разорвать.

На практике вы просто открываете https://api.example.com — шифрование и проверка сертификата выполняются автоматически. Предупреждение браузера или клиента о «ненадёжном сертификате» означает, что проверка не прошла (самоподписанный сертификат, подмена, просроченный сертификат) — в production так подключаться к API не стоит.

hashtag
Что даёт HTTPS в одном предложении

Шифрование — никто по пути не прочитает ваши пароли и токены; проверка сервера — вы общаетесь с тем API, с которым думаете; целостность — ответ по пути не подменят. Поэтому современные API почти всегда доступны по https://..., а не по http://. В практических заданиях используйте только HTTPS-адреса.

hashtag
4. Как работает API

hashtag
Из чего состоит HTTP-запрос

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

Часть запроса
Что это
Зачем используется

Метод (HTTP Method)

Глагол в начале запроса: GET, POST, PUT, PATCH, DELETE и др.

Говорит серверу действие: получить данные (GET), создать (POST), изменить (PUT/PATCH), удалить (DELETE). Один и тот же URL с разными методами может означать разное.

URL (адрес)

Полный адрес ресурса, например https://api.example.com/users/1?fields=name,email

Показывает куда отправлять запрос: какой хост, какой путь (endpoint), иногда параметры в строке запроса (query).

Заголовки (Headers)

Пары «имя: значение», по одной на строку.

Метаданные запроса: тип и язык данных, авторизация, идентификация клиента и т.д. Тело запроса заголовками не является.

Тело запроса (Body)

Произвольные данные (текст, JSON, форма и т.д.).

Передаётся не у всех запросов: в основном у POST, PUT, PATCH. Содержит данные для создания или обновления ресурса (например, JSON с полями пользователя).

Метод и URL есть у каждого запроса. Заголовки — почти всегда (хотя бы минимальный набор). Тело — только когда нужно отправить данные (POST/PUT/PATCH).

hashtag
URL: из чего он состоит

Пример: https://api.company.com/users/42?fields=name,email&sort=created

  • Схема — https:// (реже http://). Определяет протокол.

  • Хост — api.company.com. Домен сервера API.

  • Путь (path) — /users/42. Ресурс или действие (endpoint). Часто определяет «что»: пользователи, заказы, документ с ID 42.

  • Строка запроса (query) — ?fields=name,email&sort=created. Параметры «как отдать»: какие поля вернуть, сортировка, фильтры, пагинация. Начинается с ?, пары ключ=значение через &.

В документации API обычно пишут базовый URL и путь: GET /users/42, параметры query перечисляют отдельно.

hashtag
Кодирование GET-параметров (почему в URL «кракозябры»)

В URL разрешены только определённые символы: латинские буквы, цифры, дефис, подчёркивание, точка и несколько служебных. Пробелы, русские буквы, кавычки, символ &, =, ? и т.д. в значении параметра нельзя передавать «как есть»: они сломали бы разбор URL (например, & разделяет пары параметров, пробел в URL недопустим). Пробелы и спецсимволы кодируют — заменяют на последовательность %XX, где XX — код байта в шестнадцатеричном виде. Это называется percent encoding (URL encoding).

Зачем кодировать: чтобы любое значение (с пробелами, кириллицей, спецсимволами) можно было безопасно вставить в строку запроса и однозначно распарсить на другой стороне.

Полный пример. Вы хотите поиск по имени «Иван Петров» и фильтр «тест»:

  • Вы вводите (или передаёте в коде): параметр name=Иван Петров, параметр filter=тест.

  • Логически запрос такой: GET /api/search?name=Иван Петров&filter=тест.

Но в URL нельзя оставить пробелы и кириллицу «как есть». После кодирования запрос реально выглядит так:

Вот откуда в адресной строке или в логах «кракозябры»: это закодированные «Иван Петров» и «тест». Сервер при приёме декодирует обратно и видит нормальный текст.

Отдельные символы:

Символ
В URL после кодирования
Зачем

Пробел

%20 или +

В URL пробела быть не может

&

%26

Иначе его примут за разделитель параметров

=

%3D

Иначе примут за разделитель ключа и значения

Русская «а»

%D0%B0

Кириллица кодируется байтами UTF-8

Браузер, Postman и нормальные HTTP-библиотеки кодируют и декодируют сами. Если собираете URL вручную в коде — обязательно используйте функцию кодирования (encodeURIComponent в JavaScript, urlencode в Python и т.п.), иначе при пробелах или спецсимволах запрос сломается или сервер получит не те данные.

hashtag
Пагинация

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

Зачем нужна: ограничить объём одного ответа, ускорить запросы и упростить отображение на клиенте (например, «страница 1 из 10», кнопка «Ещё» или «Следующая»).

Как запрашивают: обычно через параметры в query:

  • page + limit (или per_page): «дай страницу N по M штук». Пример: GET /users?page=2&limit=20 — вторая страница по 20 записей.

  • offset + limit: «пропусти первые K записей, верни следующие M». Пример: GET /users?offset=40&limit=20 — то же по смыслу, что страница 3 при limit=20.

  • cursor (курсор): «верни записи после такого-то маркера». Маркер выдаёт сервер в предыдущем ответе (например, next_cursor=abc123). Удобно, когда список меняется между запросами (новые элементы не сбивают нумерацию страниц).

Что приходит в ответе: кроме массива элементов часто возвращают метаданные пагинации, чтобы клиент мог нарисовать «страницу 2 из 5» или кнопку «Загрузить ещё»:

  • Отдельные поля в JSON: total (всего записей), page, per_page, total_pages, или next_cursor, has_more.

  • Либо заголовки ответа, например Link с ссылками на следующую/предыдущую страницу (по стандарту REST).

Точные имена параметров и полей в ответе указываются в документации API. В методичке при работе с учебным API (Postman) вы встретите примеры с _page и _limit.

hashtag
Заголовки: зачем нужны и что в них передают

Зачем нужны заголовки: они передают метаданные запроса и ответа — не сами данные (это в body), а описание: в каком формате данные, кто обращается, какой язык ответа нужен и т.д. Сервер и клиент по заголовкам понимают, как обрабатывать тело, нужна ли авторизация, что кэшировать. Без заголовков нельзя было бы отличить JSON от XML, отправить токен доступа или попросить ответ на русском.

Часто встречаются такие заголовки:

  • Content-Type — в каком формате тело запроса (например, application/json). Сервер по нему понимает, как разбирать body.

  • Accept — в каком формате клиент хочет ответ (например, application/json). Сервер может учесть это при формировании ответа.

  • Authorization — токен или ключ доступа (например, Bearer <token>). Нужен для защищённых endpoint’ов.

  • Accept-Language — предпочитаемый язык ответа (ru, en и т.д.).

  • Cookie — куки, которые клиент отправляет серверу (например, идентификатор сессии). Формат: имя1=значение1; имя2=значение2.

  • Другие служебные или кастомные заголовки (идентификатор запроса, ключ API и т.п.) — по документации конкретного API.

У одного запроса может быть много заголовков; у каждого — своя роль.

hashtag
Куки (Cookie): зачем нужны и как работают

Зачем нужны куки: чтобы сервер «помнил» клиента между запросами без передачи логина и пароля каждый раз. В куку кладут, например, идентификатор сессии: один раз пользователь авторизовался, сервер отдал «сохрани session_id=abc123», дальше клиент при каждом запросе шлёт эту куку — сервер по ней понимает, кто обращается. Так же через куки делают корзину, выбор языка, «запомнить меня» и т.п.

Как работают: сервер однажды отправляет в ответе заголовок Set-Cookie, клиент сохраняет пару имя=значение. При следующих запросах к тому же домену клиент автоматически добавляет заголовок Cookie с сохранёнными куки.

  • В ответе сервера: заголовок Set-Cookie — сервер говорит: «сохрани эту пару имя=значение (и опции: срок жизни, путь, secure, httpOnly)». В одном ответе может быть несколько Set-Cookie.

  • В запросе клиента: заголовок Cookie — клиент отправляет все куки для данного домена в виде строки: session_id=abc123; theme=dark.

Для API куки используют не так часто, как токены в Authorization (особенно мобильные и серверные клиенты предпочитают Bearer-токен). Но веб-приложения и часть API по-прежнему опираются на сессионные куки: после логина сервер выставляет Set-Cookie с session id, дальше клиент с каждым запросом отправляет Cookie, и сервер понимает, кто обращается. В инструментах вроде Postman куки можно задать вручную в заголовке Cookie или через управление куками (см. файл про Postman).

hashtag
Тело запроса (Body)

Используется, когда клиент отправляет данные на сервер: создать пользователя (POST), обновить профиль (PATCH), загрузить файл. Формат тела задаётся заголовком Content-Type (JSON, форма, XML и т.д.). Запросы GET и DELETE обычно тела не имеют — всё необходимое передаётся в URL (path и query) и в заголовках.

hashtag
GET- и POST-параметры: в чём разница и когда что использовать

Параметры запроса (фильтры, страница, данные формы и т.д.) можно передать в URL (query) или в теле запроса (body). От выбора метода и места передачи зависят безопасность, длина данных и семантика запроса.

Параметры в URL (query)
Параметры в теле (body)

Как передаются

В строке запроса после ?: GET /users?role=admin&sort=name

В теле запроса (JSON, form-data, x-www-form-urlencoded). Используются с методами POST, PUT, PATCH.

С каким методом

В основном GET (и иногда другие методы, если API так задумал).

POST, PUT, PATCH — когда нужно отправить данные для создания или обновления.

Видимость

Видны в адресной строке, в логах сервера, в истории браузера. Легко сохраняются в закладках и пересылаются по ссылке.

Не попадают в URL. Не светятся в истории и закладках. В логах могут быть, если сервер их пишет.

Длина и формат

Ограничены длиной URL (условно до нескольких килобайт). Только текст, пары ключ=значение.

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

Кэширование и повтор

GET с одинаковым URL считается одним и тем же запросом — браузеры и прокси могут кэшировать ответ. Ссылку можно «обновить» или отправить ещё раз — это запрос на чтение.

POST/PUT/PATCH с телом обычно не кэшируют. Повторная отправка может означать повторное действие (создать ещё один заказ и т.д.).

Когда использовать параметры в URL (GET):

  • Получение данных (списки, поиск, фильтры, сортировка, пагинация). Запрос не меняет состояние сервера — «дай мне страницу 2 по 20 записей», «покажи пользователей с role=admin».

  • Параметры не секретные и небольшие: фильтры, номера страниц, порядок сортировки, формат ответа.

  • Нужна ссылка на результат: можно скопировать URL и отправить коллеге или сохранить в закладки — тот же запрос воспроизведётся.

Когда использовать параметры в теле (POST/PUT/PATCH):

  • Создание или изменение ресурса: логин/пароль, данные нового пользователя, текст поста, загрузка файла. Семантика метода POST/PUT/PATCH — «сделай что-то с этими данными».

  • Секретные данные (пароли, токены, персональные данные) — не должны попадать в URL, историю и логи в открытом виде.

  • Большие или сложные данные (длинный текст, JSON с вложенными объектами, файлы) — в body удобнее и нет ограничения длины URL.

Кратко: GET + query — для запросов «отдай данные по таким-то условиям»; POST/PUT/PATCH + body — для «прими или обнови такие-то данные». Пароли и чувствительные данные — только в body (и по HTTPS).

В общем виде работа с API выглядит так:

  1. Клиент формирует запрос: метод, URL, заголовки и при необходимости тело (например, JSON).

  2. Запрос уходит по сети (через TCP/IP, по HTTPS) на сервер.

  3. Сервер проверяет права, находит обработчик (endpoint), выполняет логику и формирует ответ: код состояния (200, 201, 400, 401, 404, 500) и тело (часто JSON).

  4. Клиент получает ответ и обрабатывает его (парсит JSON, показывает данные, обрабатывает ошибки).

Один и тот же API могут вызывать веб-сайт, мобильное приложение, другой сервер или скрипт — формат общения один и тот же.

hashtag
5. Виды API

API бывают разными по способу доступа и формату данных.

hashtag
По способу доступа

  • Публичные (открытые) — документированы, доступны по ключу или без (например, погода, карты). Часто есть лимиты по количеству запросов.

  • Внутренние (private) — для своих сервисов или партнёров, доступ по авторизации и часто только из своей сети.

  • Партнёрские — для конкретных компаний по договору и отдельным ключам.

hashtag
По архитектуре и формату

  • REST API — самый распространённый вид. Ресурсы описываются URL, действия — методами HTTP (GET, POST, PUT, DELETE). Данные часто в JSON. Мы в методичке в основном будем работать с REST.

  • GraphQL — один URL (endpoint), а что именно нужно получить, клиент описывает в теле запроса (запрос на языке GraphQL). Удобно, когда нужны гибкие выборки данных.

  • RPC (Remote Procedure Call) — вызов удалённых «функций» по имени (например, JSON-RPC, gRPC). Часто используется внутри микросервисов.

Для начала достаточно твёрдо понимать REST: URL + метод HTTP + заголовки + тело (JSON) и ответ в виде кода и JSON.

hashtag
6. Форматы обмена данными

В теле запроса и ответа API данные передаются в каком-то формате сериализации — способе превратить структуры (объекты, массивы, поля) в байты для сети. От формата зависят размер сообщения, скорость разбора и удобство для человека. Ниже — основные форматы, с которыми можно столкнуться.

hashtag
JSON (JavaScript Object Notation)

JSON — самый частый формат в веб-API. Текстовый, читаемый человеком: объекты в {}, массивы в [], ключи в кавычках, значения — строки, числа, булевы, null или вложенные структуры.

Пример:

  • Плюсы: простой, поддерживается везде (браузер, все популярные языки), удобно отлаживать.

  • Минусы: нет комментариев, типы ограничены (нет дат/бинарных данных «из коробки»), размер сообщения больше, чем у бинарных форматов.

  • В HTTP указывают заголовок: Content-Type: application/json.

Практически все современные REST API отдают и принимают JSON — в нашей методичке мы будем работать в первую очередь с ним.

hashtag
XML (eXtensible Markup Language)

XML — текстовый формат на тегах. Раньше был основным для веб-сервисов (SOAP, RSS, конфиги).

Пример:

  • Плюсы: строгая структура, схемы (XSD), пространства имён, поддержка в корпоративных системах.

  • Минусы: многословный, разбор тяжелее, в веб-API чаще выбирают JSON.

  • В HTTP: Content-Type: application/xml или text/xml.

В новых API встречается реже, но в интеграциях с банками, госуслугами, старыми системами — по-прежнему часто.

hashtag
Protocol Buffers (Protobuf)

Protobuf — бинарный формат от Google. Структура данных описывается в .proto-файлах, а код для сериализации/десериализации генерируется под разные языки.

  • Плюсы: компактный размер, быстрый разбор, строгая схема, версионирование полей. Широко используется в gRPC и внутри крупных сервисов.

  • Минусы: нечитаемый «сырой» вид, нужны схемы и кодогенерация.

  • В HTTP обычно указывают Content-Type: application/protobuf.

Чаще всего Protobuf используют не в обычных REST, а в RPC (например, gRPC over HTTP/2).

hashtag
Другие форматы

  • MessagePack — бинарный «компактный JSON». Те же типы данных, но в бинарном виде. Меньше трафика, быстрее разбор. Иногда встречается в API и кэшах.

  • YAML — текстовый, удобен для конфигов и части документаций API (OpenAPI). В теле запросов/ответов API используется редко.

  • Form data (application/x-www-form-urlencoded или multipart/form-data) — пары «ключ–значение» и загрузка файлов. Типично для HTML-форм и загрузки файлов через API.

  • Plain text (text/plain) — обычный текст. Используется для простых ответов (например, одна строка или CSV).

hashtag
Как понять, какой формат у API

  • В документации API указывают, что отдают и что принимают (часто «JSON»).

  • В ответе сервера смотрите заголовок Content-Type (например, application/json).

  • В запросе вы сами задаёте Content-Type для тела (например, application/json при отправке JSON).

В практических заданиях по API нашей компании мы будем использовать JSON; остальные форматы полезно знать, чтобы понимать общую картину и читать чужую документацию.

hashtag
7. Инструменты для работы с API

Разработчики редко пишут запросы «руками» в коде сразу. Сначала их проверяют и отлаживают инструментами.

hashtag
Браузер

Обычный GET-запрос без сложных заголовков можно отправить, просто введя URL в адресную строку. Для POST, заголовков и тела браузер неудобен — нужны другие инструменты.

hashtag
curl

curl — консольная утилита для отправки HTTP-запросов (и не только). Удобна для быстрых проверок и для скриптов. В следующем разделе — кратко, как ею пользоваться.

hashtag
Postman / Insomnia

Графические программы для работы с API: сохраняют коллекции запросов, удобно подставлять переменные (ключи, базовый URL), смотреть ответы и тестировать сценарии. Рекомендуется установить Postman или Insomnia для практики.

hashtag
Встроенные средства языка

В коде запросы к API делают через библиотеки:

  • JavaScript/Node.js: fetch, axios;

  • Python: requests, httpx;

  • Java/Kotlin: OkHttp, Retrofit;

  • C#: HttpClient, RestSharp.

В методичке мы будем использовать и curl/Postman для «ручной» проверки, и код на выбранном языке — для автоматизации.

hashtag
8. Кратко про curl

curl (Client URL) — программа командной строки. Она умеет отправлять HTTP(S)-запросы и показывать ответ в терминале.

hashtag
Базовые примеры

GET-запрос (просто открыть URL):

GET с заголовком (например, авторизация):

POST с JSON в теле:

hashtag
Полезные опции

Опция
Значение
Назначение

-X

GET, POST, PUT, DELETE

Метод HTTP

-H

"Header: value"

Добавить заголовок (можно несколько раз)

-d

строка или данные

Тело запроса (для POST и т.п.)

-i

—

Показать заголовки ответа вместе с телом

-v

—

Подробный вывод (verbose)

В практических занятиях вы будете повторять те же запросы в curl, в Postman и в коде — так проще понять, что именно уходит на сервер и что приходит обратно.

hashtag
9. Что дальше

Вы познакомились с:

  • понятием API и его ролью;

  • основами TCP/IP и HTTP;

  • тем, зачем нужен HTTPS;

  • общей схемой «запрос → сервер → ответ»;

  • основными видами API (с фокусом на REST);

  • форматами обмена данными (JSON, XML, Protobuf и др.);

  • инструментами (curl, Postman, библиотеки в коде).

Дальше в методичке будет:

  • разбор REST и GraphQL — как устроены два подхода к API (следующий файл);

  • практика в Postman — примеры запросов к учебному REST API;

  • описание конкретного API нашей компании (endpoint’ы, авторизация, примеры);

  • практические задания: от простых GET/POST до обработки ответов и ошибок в коде;

  • рекомендации по стилю кода и типичным ошибкам при работе с API.

Переходите к следующему файлу методички (REST и GraphQL), когда будете готовы к практике.

PreviousБыстрый SVGNext02 rest graphql