Вопросы и ответы по REST API: собеседование на системного аналитика

В новом эпизоде подкаста мы обсуждаем вопросы по REST API с собеседований на позицию системного аналитика, и разбираем ответы на них с примерами. REST API это основной способ взаимодействия систем, и, как следствие, один из ключевых навыков, ожидаемых от специалистов на рынке труда.
Подкаст разделен на три основные части: теоретические вопросы; виды практических задач; вопросы по опыту работы и портфолио.
Эпизод рекомендуется к прослушиванию как для начинающих, так и для опытных системных аналитиков, стремящихся углубить свои знания в теме проектирования REST API и успешно проходить технические собеседования. Особенно рекомендуется, если у вас завтра техническое интервью 🙂
00:59 - О структуре выпуска и причине выбора темы.
02:25 - Что такое REST API и его отличия от RESTful.
10:10 - 6 главных принципов REST API.
15:52 - Структура запросов и ответов REST API: типы методов и отличия между ними.
23:50 - URL и URI. Структура URI запроса. Примеры. Query и path-параметры, headers, тело запроса и ответа, авторизация, коды состояний HTTP.
29:10 - Ресурс в контексте REST API. Связь объектов данных (ресурсов) REST API и БД.
31:05 - Query-параметры в запросе. Элементы пагинации в query-параметрах и body. Path-параметры.
36:28 - Что спрашивают по авторизации в API на собеседовании. Про безопасность. Заголовки запросов - Headers. Форматы сообщений в Body.
39:27 - Коды ответов HTTP, их назначения и какие знать обязательно. Вопросы с подвохами про отличия между кодами ответов HTTP в разных ситуациях.
43:40 - Отличия между POST и PUT. Идемпотентность. Получение данных через POST.
47:10 - Другие важные технические вопросы про асинхронные запросы и Webhook-и.
48:48 - Виды практических задач по REST API на собеседованиях для системных аналитиков.
54:00 - Вопросы про опыт работы с REST API. Рекомендация - используйте портфолио (личные демо-проекты).
56:48 - Заключение и рекомендации по самостоятельному освоению REST API.
Рекомендации в конце эпизода:
1. Книга: Арно Лоре. Проектирование веб-API
2. Канал GetAnalyst с разбором проектов по REST API - t.me/getanalysts (t.me/getanalysts)
3. Видео на KZbin-канале GetAnalyst
/ getanalyst
3.1. Связь базы данных и дизайна REST API
3.2. REST API с нуля: дизайн методов для работы менеджера с заявками автосервиса
3.3. Postman: навык тестирования REST API за вечер
4. Статья “Проектирование REST API: спорные вопросы с проектов и собеседований на системного аналитика (и не только)” habr.com/ru/articles/770226/

[@user-gd4tn8rr9k]

Спасибо огромное! Очень вовремя❤

[@GetAnalyst]

Спасибо за обратную связь! ❤️

[@user-br8is8lo6x]

Спасибо, жаль не послушал вас перед собесом)

[@GetAnalyst]

Зато теперь знаете куда идти перед собесом и что смотреть ;)

[@04Tural]

Насчет метода PATCH, что он идемпотентный можно поспорить. Он скорее частично идемпотентный или не является строго идемпотентным. К примреру, у нас есть объект "user" с полем "age". Вызов PATCH запроса с данными {"age": 30} увеличит возраст пользователя на 30 лет. Если повторно отправить точно такой же PATCH запрос с {"age": 30}, некоторые серверы могут интерпретировать его как повторное действие, увеличив возраст пользователя еще на 30 лет, а не оставив его неизменным. Таким образом, в данном случае результат не останется одинаковым, что противоречит строгой идемпотентности.

[@GetAnalyst]

Добрый день! Пример скорее вырожденный. Похоже на то, что нужен какой-то counter (счетчик) на события именно под вашу задачу. И да, его можно сделать через PATCH :) На самом деле и под GET в REST API тоже можно заложить логику измениня данных в БД в процессе получения (например, увеличение счетчикаа на кол-во просмотров). И получается, что все методы частично идемпотентны. Можно начинать рассуждения о том, когда у нас просто REST API, а когда RESTful. И хорошо, когда вы можете привести примеры с такими исключениями и войти в дискуссию на эту тему, это показывает глубокое понимание вопроса))