Продвинутый уровень (15 из 15)

<aside> <img src="/icons/calendar-day_gray.svg" alt="/icons/calendar-day_gray.svg" width="40px" />

16 июня 2026

</aside>

<aside> <img src="/icons/clock-alternate_lightgray.svg" alt="/icons/clock-alternate_lightgray.svg" width="40px" />

20 минут

</aside>

1. Какое ключевое преимущество REST делает его оптимальным для масштабируемых веб-сервисов?

   • REST опирается на стандарты HTTP и методы GET, POST, PUT, DELETE, что упрощает интеграцию и масштабирование
   • REST использует SOAP для обмена сообщениями между клиентом и сервером, дополняя его возможности
   • REST обеспечивает встроенную поддержку транзакций и надежной доставки сообщений между клиентом и сервером
   • REST требует использования сложных XML-сообщений для взаимодействия, а SOAP для обмена
   • REST основан на использовании статических IP-адресов для всех ресурсов и поэтому он быстрее

2. Ваше приложение должно взаимодействовать с RESTful API, а вы хотите протестировать корректность обработки POST-запросов. Вам необходимо проверить, что сервер правильно возвращает ошибки при некорректно сформированных данных в теле запроса. Тело запроса должно содержать JSON-объект с обязательными параметрами. Тестирование должно включать автоматическую проверку содержимого ответов на запросы.

   Какую последовательность действий следует выполнить в Postman, чтобы автоматически проверить, что сервер возвращает ошибки при некорректных данных в запросе?

   • Настроить тело запроса во вкладке Body, выбрать формат JSON, отправить запрос и записать в Tests скрипт проверки статуса ответа и текста ошибки
   • Создать новый Mock-сервер, отправить на него тестовые запросы и проверить, что возвращаются ошибки
   • Открыть вкладку Authorization и ввести токен доступа для отправки запросов
   • Сформировать коллекцию запросов и использовать Monitor для анализа ответа API
   • Включить логирование запросов в Postman и вручную анализировать содержимое ошибок

3. Вы разрабатываете API для мобильного приложения и рассматриваете использование JWT для аутентификации.

   Почему JWT может быть предпочтительным выбором для распределенной системы с большим количеством пользователей для мобильного приложения?

   • Не требует хранения состояния сессий на сервере, что облегчает масштабирование системы
   • Позволяет хранить состояние сессий на сервере, что упрощает управление пользователями
   • Автоматически обновляет токены после каждого запроса, что повышает безопасность
   • Требует больше ресурсов для обработки токенов, но обеспечивает максимальную безопасность данных
   • Поддерживает многофакторную аутентификацию и шифрование, что делает его идеальным для всех типов приложений

4. Ваш API использует настройку OpenID Connect над OAuth 2.0, выступающая в качестве протокола аутентификации для авторизации пользователей. Во время тестирования вы заметили, что повторные запросы авторизации от одного и того же пользователя не создают новую сессию, а продолжают использовать уже существующую. Это положительно повлияло на производительность и предотвращение возможных конфликтов данных.

   В чем причины таких изменений использования OpenID Connect? Такая настройка:

   • Ассоциирует токены с текущей сессией, что предотвращает их дублирование и создание новых сессий
   • Не создает новые токены, если пользователь уже имеет активный токен для текущей сессии
   • Использует статические токены, которые не подвержены привязку к сессиям
   • Требует ручной синхронизации сессий между запросами для предотвращения дублирования
   • Автоматически завершает предыдущую сессию при получении нового запроса, чтобы избежать конфликта

5. Ваш API обрабатывает запросы на обновление ресурса. Клиент отправляет запрос с некорректным синтаксисом в теле, например, отсутствует обязательное поле идентификатора ресурса, которого нет в системе. Сервер должен выбрать приоритетную ошибку, чтобы корректно уведомить клиента о причине отказа.

   Почему в этой ситуации сервер должен использовать код 400 для обработки ошибки?

   • Синтаксическая ошибка в теле запроса делает невозможным дальнейшую обработку, включая проверку существования ресурса
   • Код указывает клиенту на проблему с самим запросом, требующую исправления перед дальнейшей обработкой
   • Обработка данных в запросе предшествует проверке существования ресурса, делая эту ошибку первоочередной
   • Синтаксическая ошибка нарушает структуру запроса, что делает проверку ресурса нерелевантной
   • Сначала необходимо исправить синтаксис запроса, прежде чем сервер сможет проверить существование указанного ресурса

6. Ваша микросервисная система обрабатывает заказы в режиме реального времени. Разные узлы могут одновременно обновлять одни и те же заказы. При этом клиенты порой дублируют запросы PUT или PATCH, пытаясь гарантированно применить изменения, а также повторяют запросы после таймаутов. Вам нужно обеспечить идемпотентность и избежать «гонок», из-за которых один узел может перезаписать изменения другого, нарушая согласованность данных.

   Какой подход к CRUD-операциям позволит эффективно поддерживать идемпотентность и управление конкурентными обновлениями в распределенной среде?

   • Применять PUT с условными заголовками, чтобы при конфликте версий сервер отклонял повторные запросы или запросы с устаревшими данными
   • Хранить все изменения в очереди и выполнять их последовательно на одном узле, исключая параллельную обработку
   • Отключить частичное обновление (PATCH) и всегда создавать новые ресурсы при изменении, избегая одновременных операций над одним заказом
   • Разрешать клиентам отправлять дубликаты запросов POST для актуализации информации, полагаясь на уникальный ключ в теле запроса
   • Использовать простые PUT-запросы без версии ресурса, позволяя любому узлу перезаписывать поля независимо от текущего состояния

7. При выполнении массового обновления профилей пользователей методом PUT некоторые клиенты получают разные результаты при повторных запросах, хотя метод PUT должен быть идемпотентным. Нужно определить, какие факторы могут вызывать такие непредсказуемые результаты, и как они связаны с принципом идемпотентности.

   Какое из свойств метода PUT или серверной обработки может нарушить идемпотентность в данном случае?

   • Параллельная обработка PUT-запросов, вызывающая несогласованность данных
   • Метод PUT не поддерживает повторные запросы на массовое обновление
   • Отсутствие уникального идентификатора, что приводит к созданию новых записей
   • Наличие кэширования, из-за которого сервер возвращает устаревшие данные
   • Некорректная обработка заголовка Content-Type, из-за чего сервер игнорирует некоторые параметры

8. Ваш API обновляет данные профилей пользователей. При высокой нагрузке возникает множество повторяющихся PUT-запросов почти одновременно, что приводит к лишней записи в базу данных и конфликтам в распределенной среде. Из-за этого часть запросов дублирует уже внесенные изменения или отправка тех же данных не меняла итоговое состояние.

   Как обеспечить корректную обработку повторных PUT-запросов, сохраняя идемпотентность метода?

   • Проверить, совпадают ли данные из нового запроса с текущими данными
   • Добавить параметр timestamp в каждый запрос для предотвращения коллизий
   • Переключить метод с PUT на PATCH, чтобы ограничить повторное обновление
   • Использовать кэширование, чтобы блокировать повторные запросы от одного клиента
   • Переключить логику обработки на асинхронный режим

9. Вы реализовали систему уведомлений на WebSocket, но теперь требуется поддерживать дополнительные протоколы, такие как SSE и Webhooks, для других клиентов. Вам нужно сделать систему расширяемой, обеспечить идемпотентность и избежать гонок данных между клиентами.

   Какой подход вы выберете для поддержки нескольких протоколов уведомлений?

   • Использовать брокер сообщений для централизованной обработки событий и отправки через разные протоколы
   • Реализовать поддержку дополнительных протоколов на уровне клиента и отправку через разные протоколы
   • Разделить сервер на отдельные модули для обработки и отправки через разные протоколы
   • Переключиться на единственный протокол, например, SSE, чтобы избежать сложности отправки через разные протоколы
   • Применить кэширование для синхронизации данных между клиентами и отправки данных через разные протоколы

10. Вы планируете опубликовать свое API для внешних разработчиков и хотите предоставить актуальную документацию, которая автоматически обновляется при изменениях в коде. Список факторов:

    1. Использование аннотаций кода для генерации документации.
    2. Возможность преобразования спецификации OpenAPI в различные языки программирования.
    3. Генерация пользовательского интерфейса (UI), который отображает текущее состояние API.

    Какие из перечисленных факторов связаны с поддержкой автоматического обновления документации в OpenAPI?

    • Факторы 1 и 3
    • Только фактор 1
    • Все три фактора
    • Только фактор 2
    • Только фактор 3

11. Ваш API должен быть совместим с клиентами, которые работают с различным форматом данных. У некоторых клиентов устаревшие системы, принимающие только XML, тогда как другие используют современные приложения, требующие JSON. Вы хотите, чтобы сервер оставался универсальным, позволяя клиентам выбирать предпочтительный формат ответа с минимальными изменениями в коде. При этом нужно учесть REST-подход и оптимальную поддержку content-negotiation.

    Какой из перечисленных ниже, самый оптимальный способ организации API, дающий возможность клиенту выбирать предпочтительный формат данных в ответе?

    • Использовать заголовок Accept в HTTP-запросе
    • Использовать параметр в URL
    • Предоставить разные эндпоинты для каждого формата
    • Использовать для этого параметр query
    • Определить формат ответа на основе выбранного клиентом соответствующего IP-адреса

12. Вы хотите обеспечить безопасную передачу JWT-токенов между клиентом и сервером. Клиенты вашего API могут использовать как браузеры, так и мобильные приложения.

    Какой метод хранения и передачи токенов лучше всего подходит для обеспечения безопасности JWT?

    • Использовать куки с атрибутами HttpOnly и Secure для хранения токенов
    • Передавать JWT-токен в URL-параметрах при каждом полученном запросе
    • Хранить JWT у клиента и добавлять его в запрос через URL-параметры
    • Сохранять JWT на сервере и передавать его в теле каждого ответа
    • Хранить JWT в Local Storage и передавать его в запросах через HTTP-заголовок Authorization

13. Ваша компания переходит на микросервисную архитектуру. Данные о пользователях хранятся в одном сервисе, а информация о заказах – в другом. Вы хотите, чтобы клиент мог одним GraphQL-запросом получить всю нужную информацию – например, профиль пользователя и историю его заказов, не обращаясь к нескольким эндпоинтам отдельно. Необходимо обеспечить объединение данных из нескольких микросервисов, сохраняя единый GraphQL-шлюз (gateway).

14. Ваш API должен быть доступен только для определенной группы клиентов, которые аутентифицируются через API-ключи. У каждого клиента есть уникальный ключ, и ваша цель – обеспечить:

15. Ваш API поддерживает запросы, возвращающие большие массивы данных, до 100 000 записей, но клиенты редко используют более 10% этих данных. Например: