25 ключевых вопросов и ответов на собеседовании по REST API

В индустрии разработки программного обеспечения интеграция играет ключевую роль при разработке приложений. Одной из основных технологий для этого является REST API . Знание REST API — важный навык для каждого технического специалиста. В этой статье мы представим 25 вопросов по REST API, которые помогут вам подготовиться к собеседованию и улучшить свои навыки. Наслаждайся чтением!

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

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

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

1. Что такое ОТДЫХ?

Ответ: При упоминании REST используются три термина, которые часто считаются одним и тем же, но это не совсем так. Этими терминами являются REST, REST API и RESTful API. Теперь будет ответ про REST, этот термин расшифровывается как Representational State Transfer и представляет собой архитектурный стиль, основанный на протоколе HTTP (протокол передачи гипертекста) для разработки приложений, имеющих интерфейс и/или интеграцию с внешними системами. REST описывает рекомендации, которым должны следовать разрабатываемые API-сервисы. Эти принципы гарантируют, что запросы передаются между клиентом и сервером с использованием HTTP.

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

Ответ: API — это программный интерфейс, который позволяет отдельным приложениям взаимодействовать и обмениваться данными. Например, приложение для доставки еды может использовать API Google Maps, чтобы отслеживать местоположение курьера и отображать его на карте. 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 должны следовать двум основным принципам: Разделение на клиента и сервер: Взаимодействие между клиентом и сервером осуществляется в форме запросов и ответов. Только клиенты могут отправлять запросы, и только серверы могут отправлять ответы, чтобы работать независимо друг от друга. Единый протокол: Взаимодействие между клиентом и сервером должно осуществляться по единому протоколу. Для REST это протокол HTTP.

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

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

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

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

7. Что такое URL-адрес?

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

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

Ответ: CRUD означает «Создать, прочитать, обновить, удалить». Это четыре основных действия, которые можно выполнять с базами данных через REST API. Каждое действие имеет свой метод HTTP-запроса:

• Создать = ПОСТ
• Чтение = ПОЛУЧИТЬ
• Обновление = ПОСТАВИТЬ
• Удалить = УДАЛИТЬ

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

Ответ: Полезная нагрузка HTTP-ответа относится к данным ресурса, запрошенным клиентом. Это также кратко называется «полезная нагрузка ответа HTTP». Эти данные могут быть в формате JSON, XML, HTML, изображениях, файлах и т. д., в зависимости от того, что именно предоставляет сервер.

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

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

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

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

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

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

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

• GET: запрашивает ресурс с сервера, этот метод доступен только для чтения.
• POST: Создает новый ресурс на сервере.
• PUT: обновляет существующий ресурс на сервере.
• УДАЛЕНИЕ: удаляет ресурс с сервера.

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 ОК: запрос выполнен успешно.
• 201 Создано: запрос выполнен успешно, ресурс создан.
• 202 Принято: этот статус означает, что сервер принял запрос клиента, но не завершил его обработку. Обработка может быть асинхронной.

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

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

• 301 Перемещено навсегда: этот статус сообщает клиенту, что запрошенный ресурс был окончательно перемещен на другой URL-адрес, и клиент должен получить доступ к новому URL-адресу, чтобы получить доступ к ресурсу.
• 302 Найдено: этот статус указывает, что ресурс был временно перемещен на другой URL-адрес, и клиент должен временно использовать новый URL-адрес.
• 307 Временное перенаправление: аналогично 302, но клиент должен использовать тот же метод запроса при доступе к новому URL-адресу.
• 308 Постоянное перенаправление: аналогично 301, но клиент должен использовать тот же метод запроса при доступе к новому URL-адресу.

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

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

• 400 Bad Request: запрос не был выполнен из-за ошибки в запросе, например опечатки или отсутствия данных.
• 401 Несанкционировано: запрос не был выполнен, поскольку клиент не прошел аутентификацию или не имеет разрешения на доступ к запрошенному ресурсу.
• 403 Запрещено: запрос не был выполнен, поскольку клиент прошел аутентификацию, но не авторизован для доступа к запрошенному ресурсу.
• 404 Not Found: запрос не был выполнен, поскольку серверу не удалось найти запрошенный ресурс.

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

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

• 500 Внутренняя ошибка сервера: запрос не был выполнен из-за неожиданной проблемы на сервере.

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

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

  
  

20. В чем разница между REST и GraphQL

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

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

Ответ: REST и SOAP (простой протокол доступа к объектам) — это два подхода к созданию API. Между ними есть 3 основных различия:

• SOAP — это строгий протокол для создания безопасных API. REST — это не протокол, а архитектурный стиль, продиктованный набором правил, называемых принципами REST. - API-интерфейсы REST проще в создании, легче и, как правило, быстрее, чем API-интерфейсы SOAP.
• API-интерфейсы SOAP считаются более безопасными, чем API-интерфейсы REST, хотя API-интерфейсы REST по-прежнему могут реализовывать функции безопасности, делающие их достаточно безопасными. — 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. Что такое подход «Сначала контракт» к разработке 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, а затем на основе этой функциональности автоматически генерируется спецификация API. Отличительной чертой подхода Code First является то, что разработчики сосредотачиваются на написании логики API и используют инструменты, которые позволяют им автоматически создавать документацию и спецификации на основе этой логики.

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

Я надеюсь, что эта статья поможет вам подготовиться к собеседованию или освежить свои знания о REST API.