В индустрии разработки ПО системный аналитик играет ключевую роль в проектировании приложений и построении интеграций. Одним из основных инструментов для этого является REST API. Знание REST API — важный навык для системного аналитика, наряду с диаграммами BPMN и UML Sequence, и умением составлять SQL-запросы. В этой статье мы представим 25 вопросов по REST API, которые помогут вам подготовиться к интервью на вакансию системного аналитика (СА) и прокачать свои навыки. Полезного чтения!

Вначале надо сказать, что сегодняшняя статья с вопросами по теории REST API — это продолжение обзорной статьи «Как пройти техническое интервью на позицию системного аналитика в финтех-проект». Если вы хотите узнать, как в целом проходит такое интервью, то рекомендуем посмотреть эту статью. Сейчас мы подробнее рассмотрим тот этап технического интервью, в котором проверяются знания кандидата по теории REST API.
И вот, что еще хочется добавить, прежде чем перейти к списку вопросов и ответов:

• Во-первых, вопросы по REST API интервьюер обычно делит на теоретические и практические. Вначале задает 2-3 теоретических вопроса по терминологии, по методам HTTP-запросов, а потом вы получаете практическое задание по составлению какого-либо запроса.

• Во-вторых, в этой статье собраны часто задаваемые теоретические вопросы, а примеры практических заданий по REST API мы планируем выложить в следующей статье нашего блога. Более того, будет еще и бонусная статья, в которой собраны особо сложные задания по REST API, когда от кандидата (СА с навыками разработчика) потребуется уже начальное знание Python, Java или JavaScript.

• И, в-третьих, мы не знаем заранее, какие вопросы вам достанутся на интервью в SSP SOFT, и тем более, — о чем спрашивают СА по этой теме в других компаниях. Но уверены, что в процессе проработки нашего списка типовых вопросов, вы наверняка углубитесь в тему, и тем самым прокачаете свои знания по REST API.

Открыты вакансии системного аналитика, разработчиков на Java, React и Python, 1С, инженеров DevOps и QA — приглашаем посетить нашу страницу на hh.ru.

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

Блок вопросов по терминологии REST API

Начните подготовку к интервью с этого раздел по терминологии и принципам REST API. Для наглядного объяснения принципов REST API можно также посмотреть вот это видео от IBM (есть русские субтитры).

1. Что такое REST?

Ответ: Используется три термина REST, которые часто считают одним и тем же, но это не совсем верно. Эти термины: REST, REST API и RESTful API.

Сейчас будет ответ про REST, термин расшифровывается как Representational State Transfer и представляет собой архитектурный стиль, основанный на HTTP-протоколе (Hypertext Transfer Protocol) для разработки приложений, имеющих фронтенд и/или интеграцию с внешними системами.

REST описывает рекомендации, которым должны следовать проектируемые сервисы API. Эти принципы обеспечивают передачу запросов между клиентом и сервером с использованием HTTP.

2. Что такое REST API?

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

REST API — это API, соответствующий принципам REST, когда все данные рассматриваются как ресурсы, каждый из которых представлен уникальным унифицированным идентификатором ресурса (URI).

3. Что такое RESTful API?

Ответ: RESTful API — это API, разработанный согласно правилам (или, еще можно сказать, «принципам») REST.

Иными словами, разница между REST API и RESTful API носит терминологический характер. В первом случае подразумевается свод правил REST, а во втором — реализация конкретного API в соответствии с правилами REST.

Термин RESTful API часто заменяют на REST API или даже REST исключительно ради краткости. Когда системные аналитики на диаграмме работы приложения рисуют стрелки с надписями REST, то подразумевается RESTful API.

4. Каковы два основных принципа работы REST?

Ответ: Запросы REST API должны соответствовать двум основным принципам:

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

2. Единый протокол: Взаимодействие между клиентом и сервером должны осуществляться по единому протоколу. Для REST таким протоколом является HTTP.

5. Какие еще принципы работы REST вы знаете?

Ответ: Можно назвать еще как минимум 4 принципа. Запросы REST API не сохраняют статуса на сервере, могут проходить через слои серверов и кэшироваться. Также можно отправлять клиентам исполняемый код в ответе сервера.

• Бесстатусное состояние (Stateless) сервера: Сервер не хранит никакой информации о прошлых запросах/ответах. Каждый запрос и ответ содержат всю информацию, необходимую для завершения взаимодействия. Бесстатусное взаимодействие снижает нагрузку на сервер, экономит память и повышает производительность.

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

• Кэшируемость: В ответах сервера указывается, является ли его ресурс кэшируемым, чтобы клиенты могли кэшировать любые ресурсы для повышения производительности.

• Код по запросу (Code on demand): Сервер может отправлять исполняемый код клиентам в своем ответе для исполнения внутри клиентского приложения.

6. Что такое ресурс?

Ответ: В концепции REST каждый доступный объект на стороне сервера обозначается как ресурс. Ресурс — это объект, имеющий тип, связанные с ним данные, связь с другими ресурсами на сервере и список методов, которые могут быть использованы для работы с ним. Например, ресурсом может быть HTML или текстовый файл, файл данных, изображение или видео, файл исполняемого кода.

Ресурс идентифицируется с помощью унифицированного идентификатора ресурса, или URI. Клиенты получают доступ к ресурсам, используя их URI в HTTP-запросах.

7. Что такое URI?

Ответ: URI означает унифицированный идентификатор ресурса. Это строка, которая идентифицирует ресурс на сервере. Каждый ресурс имеет свой уникальный URI-идентификатор, который, будучи включенным в HTTP-запрос, позволяет клиентам обращаться к этому ресурсу и выполнять над ним действия. Процесс обращения к ресурсу с помощью его URI называется "адресацией".

8. Что такое CRUD?

Ответ: CRUD расшифровывается как "Create, Read, Update, Delete". Это четыре основных действия, которые можно выполнять с базами данных через REST API. Каждому действию соответствует свой метод HTTP-запроса:

Создать = POST
Прочесть = GET
Обновить = PUT
Удалить = DELETE

9. Что в ответе сервера подразумевается под полезной нагрузкой?

Ответ: Под полезной нагрузкой HTTP-ответа подразумеваются данные ресурса, которые были запрошены клиентом. Это кратко также называют "HTTP response payload".

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

10. Что такое обмен сообщениями в REST?

Ответ: Под обменом сообщениями в REST понимается обмен сообщениями между клиентом и сервером. Взаимодействие всегда начинается с того, что клиент обращается к серверу с HTTP-запросом. Сервер обрабатывает этот запрос, а затем отправляет обратно HTTP-ответ, в котором указывается статус запроса и все ресурсы, которые запрашивал клиент.

11. Что такое брокер сообщений в REST?

Ответ: В контексте REST, термин "брокер сообщений" — это промежуточное программное обеспечение (middleware), которое служит для передачи сообщений между различными компонентами или системами в распределенном приложении. Брокер может обеспечивать асинхронный обмен данными, очередь сообщений и обработку сообщений между различными модулями системы.

Брокеры сообщений могут использоваться для управления асинхронными операциями или отправки уведомлений. Брокер сообщений не является нативным элементом REST, т.к. REST ориентирован на синхронное взаимодействие между клиентом и сервером с использованием HTTP-запросов.

Блок вопросов по функционированию RESTful API

В этом разделе речь пойдет о проверке знаний RESTful API, т.е. реализации принципов REST для API приложений. Если вы любите смотреть и слушать, вот это видео на YouTube будет полезно (видео на англ. яз., включите субтитры и нажмите "Перевести", чтобы читать русские субтитры для лучшего понимания материала).

Вопросы и ответы в видео частично совпадают с нашим списком.

12 Какие методы HTTP-запросов поддерживаются REST?

Ответ: Метод HTTP-запроса указывает желаемое действие, которое сервер выполнит над ресурсом. В REST существует четыре основных метода HTTP-запросов клиента к серверу:

• GET: Запрашивает ресурс у сервера, этот метод только для чтения.

• POST: Создает новый ресурс на сервере.

• PUT: Обновляет существующий ресурса на сервере.

• DELETE: Удаляет ресурс с сервера.

13. В чем разница между методом POST и методом PUT?

Ответ: POST предназначен для создания ресурса на сервере, в то время как PUT — для замены ресурса на определенном URI другим ресурсом. Если использовать PUT на URI, который уже имеет связанный с ним ресурс, PUT заменит его. Если ресурс на указанном URI отсутствует, PUT создает его.

PUT является идемпотентным, то есть его многократный вызов приведет к созданию только одного ресурса. Это происходит потому, что каждый вызов заменяет существующий ресурс (или создает новый, если заменять нечего).

POST не является идемпотентным. Если, к примеру вызвать POST 10 раз, то на сервере будут созданы 10 различных ресурсов, каждый со своим URI. 

Хотя это редко применяется, ответы POST можно кэшировать, а ответы PUT нельзя. Запросы POST обычно считаются некешируемыми, но их можно кешировать, когда они содержат ясную информацию о “свежести” данных. Подробнее можно ответить так, что ответ для запроса POST (или PATCH) может быть закеширован, если указан признак "свежести" данных и установлен заголовок Content-Location (en-US), но это редко реализуется. Поэтому кэширование POST стоит избегать, если это возможно.

14. Из каких основных частей состоит HTTP-запрос?

Ответ: В REST существуют следующие основные компоненты HTTP-запроса:

• Метод запроса, который будет выполняться к ресурсу (т.е. GET, POST, PUT, DELETE).

• URI, идентифицирующий запрашиваемый ресурс на сервере.

• Версия HTTP, – т.е. какая версия должна быть в ответе сервера.

• Заголовок HTTP-запроса содержит метаданные о запросе, такие как агент пользователя, форматы файлов, принимаемые клиентом, формат тела запроса, язык, предпочтения по кэшированию и т.д.

• Тело HTTP-запроса, оно содержит все данные, связанные с запросом. Это необходимо только в том случае, если запрос направлен на изменение данных на сервере с помощью методов POST или PUT.

15. Каковы основные части HTTP-ответа?

Ответ: Ответы HTTP отправляются от сервера клиенту. Они информируют клиента о том, что запрошенное действие было (или не было) выполнено, и о доставке любых запрошенных ресурсов. Существует четыре основных компонента HTTP-ответа:

• Используемая версия HTTP.

• Строка состояния со статусом запроса и кода состояния HTTP-ответа.

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

• Тело HTTP-ответа с данными о ресурсе, который был запрошен клиентом

16. Назовите как минимум 3 кода успешных HTTP-ответов сервера

Ответ: сервер возвращает следующие коды статуса операции при успешной обработке запроса:

• 200 OK: Запрос выполнен успешно.

• 201 Created: Запрос прошел успешно, и ресурс был создан.

• 202 Accepted: Этот статус означает, что сервер принял запрос клиента, но не завершил его обработку. Обработка может быть асинхронной.

17. Назовите как минимум 4 кода HTTP-ответа сервера при перенаправлении запроса

Ответ: сервер возвращает следующие коды статуса при перенаправлении запроса:

• 301 Moved Permanently: Этот статус говорит клиенту, что запрошенный ресурс был постоянно перемещен на другой URL, и клиент должен обращаться к новому URL для доступа к ресурсу.

• 302 Found: Этот статус указывает на то, что ресурс временно перемещен на другой URL, и клиент должен временно использовать новый URL.

• 307 Temporary Redirect: Аналогично коду 302, но клиент должен использовать тот же метод запроса при обращении к новому URL.

• 308 Permanent Redirect: Аналогично 301, но клиент должен использовать тот же метод запроса при обращении к новому URL

18. Назовите как минимум 4 кода неуспешных HTTP-ответов сервера.

Ответ: сервер возвращает следующие коды при неуспешной обработке запроса:

• 400 Bad Request: Запрос не был выполнен из-за ошибки в запросе, например, опечатки или отсутствия данных.

• 401 Unauthorized: Запрос не был выполнен, поскольку клиент не прошел аутентификацию или не имеет права доступа к запрашиваемому ресурсу.

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

• 404 Not Found: Запрос не был выполнен, поскольку сервер не смог найти запрашиваемый ресурс.

19. Назовите как минимум 3 кода ошибки сервера.

Ответ: сервер возвращает следующие коды при ошибке на сервере:

• 500 Internal Server Error: Запрос не был выполнен из-за непредвиденной проблемы с сервером.

• 502 Bad Gateway: Запрос не был выполнен из-за некорректного ответа от вышестоящего сервера.

• 503 Service Unavailable: Сервер не смог обработать запрос из-за технического обслуживания, перегрузки или других временных помех.

Блок вопросов о подходах к разработке и отличиях REST от других технологий

Кроме REST, сузествуют и другие подходы к построению API и взаимодействию клиента и сервера. СА должен как минимум знать о существовании таких технологий. Еще одно видео от IBM поможет вам в ответе на частый вопрос об отличии REST и GraphQL (включите субтитрыи и нажмите "Перевести", чтобы читать русские субтитры).

20. Назовите разницу между REST и GraphQL

Ответ: GraphQL — это язык запросов, который позволяет клиентам запрашивать только те данные, которые им нужны. В GraphQL клиент определяет структуру и формат данных, которые он хочет получить, и сервер возвращает их в соответствии с этим запросом.

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

21. В чем разница между REST и SOAP?

Ответ: REST и SOAP (Simple Object Access Protocol) — это два разных подхода к построению API. Вот 3 основные различия между ними:

• SOAP — это строгий протокол для построения безопасных API. REST — это не протокол, а архитектурный стиль, продиктованный набором рекомендаций, еще называемых принципами REST.
  - REST API проще в построении, легче и, как правило, быстрее, чем SOAP API.

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

• SOAP кодирует данные в формате XML.
  - REST позволяет кодировать данные в любом формате, хотя наиболее популярны XML и JSON.

22. В чем разница между REST и AJAX?

Ответ: Асинхронный JavaScript, или AJAX — это набор технологий веб-разработки, используемых в веб-приложениях. По своей сути AJAX позволяет веб-странице выполнять запросы к серверу и обновлять интерфейс страницы без необходимости обновления всей страницы.

AJAX-клиент может использовать в своих запросах REST API, но AJAX не обязательно должен работать только с REST API. REST API могут взаимодействовать с любым клиентом, независимо от того, использует он AJAX или нет.

Кроме того, в отличие от REST, где для обмена сообщениями используются HTTP-запросы и ответы, AJAX посылает свои запросы на сервер с помощью объекта XMLHttpRequest, встроенного в JavaScript. Ответы сервера выполняются JavaScript-кодом страницы для изменения ее содержимого.

23. Что такое подход "Contract First" к разработке REST API?

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

24. В чем состоят преимущества Contract First?

Ответ: Можно назвать следующие преимущества подхода Contract First:

• Четкое определение API: Спецификация и контракт API определяют, как API должно взаимодействовать с клиентами.

• Уменьшение рисков: Предварительное согласование контракта с заказчиками помогает уменьшить риски недопонимания и несоответствия ожиданиям от разработки API.

• Улучшенная документация: Текст контракта часто служит документацией для API, что упрощает его использование и интеграцию.

25. Что такое Code First подход к разработке REST API?

Ответ: Подход Code First в разработке REST API — это методология, при которой сначала разрабатывается функциональность API, а затем на основе этой функциональности автоматически генерируется спецификация PI. Отличительной чертой Code First подхода является то, что разработчики фокусируются на написании логики API и используют инструменты, которые позволяют автоматически создавать документацию и спецификацию на основе этой логики.

В принципе, оба подхода, Code First и Contract First, можно сочетать в рамках одного проекта разработки API. В этом случае, Code First используется для быстрого прототипирования, а затем Contract First для формализации контракта.

Заключение

В этой статье мы рассмотрели 25 вопросов, которые могут быть заданы по теме REST API на техническом интервью на вакансию системного аналитика. Эти вопросы охватывают основные принципы REST и HTTP, и также более глубокие аспекты проектирования и разработки RESTful API.

Подготовка к интервью по REST API требует хорошего понимания принципов архитектуры REST, HTTP-методов и статус-кодов, а также навыков работы с запросами и ответами. 

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

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

Всех интересующихся вакансиями системного аналитика, разработчиков на Java, React и Python, 1С, инженеров DevOps и QA — приглашаем посетить нашу страницу на hh.ru.
Удачи вам на интервью и в дальнейшем росте в области RESTful API.

Автор: Сергей Березин