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

Размышления и личный опыт

Онлайн-тесты, особенно по таким узким темам, как API, всегда воспринимаются мной как своеобразный «чек-ап» компетенций. Казалось бы, формальные задания с пятью-шестью вариантами ответов, но на деле за ними стоит множество важных нюансов, которые проверяют не только знания, но и способность быстро принимать рациональные решения.

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

В процессе решения теста, я заметил интересную закономерность: самый очевидный ответ не всегда оказывается правильным. Иногда подходы, кажущиеся логичными на первый взгляд, не выдерживают критики при детальном разборе. Например, с REST и SOAP: REST действительно легче масштабируется и прост в реализации, но понимать нужно, почему именно он подходит под конкретную задачу лучше, чем более «тяжёлый» SOAP. Или, скажем, контент-негациация, где правильным выбором становится не создание множества отдельных точек, а грамотное использование HTTP-заголовков.

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

Вопрос 1

Какое основное отличие REST от SOAP, которое влияет на выбор между ними при разработке легковесных и масштабируемых веб-сервисов?

Варианты ответов:

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

Обоснование:

Вариант 1 неверен, так как именно REST обеспечивает более простую масштабируемость, используя стандартные HTTP-методы без сложных спецификаций.
Вариант 2 неверен, так как именно SOAP требует строгого определения контрактов через WSDL, а REST — нет.
Вариант 3 неверен, так как REST полностью поддерживает методы HTTP (GET, POST, PUT, DELETE).
Вариант 4 верен, так как REST является простым, легким, использует стандартный HTTP и не требует сложных спецификаций и стандартов, в отличие от SOAP, который опирается на сложные форматы обмена сообщениями (XML, WSDL, SOAP-конверты и т.д.).
Вариант 5 неверен, так как SOAP изначально поддерживает формат XML, а REST допускает использование различных форматов данных (XML, JSON и других).

Выбранный ответ: 4. REST использует более простой и легкий протокол HTTP и не требует сложных стандартов обмена сообщениями.

Вопрос 2

Вы используете Swagger для документирования своего RESTful API. Вам нужно предоставить разработчикам возможность интерактивно тестировать API прямо из документации.
Какую функцию Swagger вы можете использовать для достижения этой цели?

Варианты ответов:

Интегрировать Swagger с Postman для удобного импорта коллекций и тестирования API прямо из документации
Использовать Swagger Codegen для создания любых клиентских библиотек API
Использовать Swagger UI для создания интерактивной документации с возможностью тестирования запросов
Генерировать статические HTML-страницы с описанием API и необходимыми примерами
Экспортировать спецификацию API в формат PDF для удобного его распространения

Обоснование:

Вариант 1 неверен, поскольку интеграция с Postman не является основной функцией Swagger и не позволяет интерактивно тестировать API непосредственно в документации Swagger.
Вариант 2 неверен, так как Swagger Codegen предназначен для автоматической генерации клиентских библиотек и кода, а не для интерактивного тестирования API.
Вариант 3 верен. Swagger UI специально создан для предоставления интерактивной документации с возможностью отправки запросов к API непосредственно из браузера, позволяя разработчикам напрямую тестировать API.
Вариант 4 неверен, так как статические HTML-страницы не позволяют интерактивно выполнять запросы.
Вариант 5 неверен, поскольку экспорт API в PDF не даёт возможности проводить интерактивные тесты, это просто статичная документация.

Выбранный ответ:
3. Использовать Swagger UI для создания интерактивной документации с возможностью тестирования запросов

Вопрос 3

При разработке защищенного API вы рассматриваете использование Basic Authentication или OAuth 2.0.
Какое ключевое преимущество OAuth 2.0 будет для вас самым значимым по сравнению с Basic Authentication в контексте безопасности и управления доступом?

Варианты ответов:

Проще реализуем, и не требует дополнительной настройки сервера для управления доступом
Обеспечивает автоматическое обновление токенов доступа, и проще в настройке по сравнению с Basic Authentication
Быстрее и проще поддерживает многофакторную аутентификацию, в отличие от Basic Authentication
Позволяет предоставлять ограниченный доступ к ресурсам без передачи учетных данных пользователя
Использует более простой процесс аутентификации, основанный на использовании токенов сессии

Обоснование:

Вариант 1 неверен. OAuth 2.0 сложнее, чем Basic Authentication, и требует дополнительной настройки.
Вариант 2 неверен, поскольку OAuth 2.0, наоборот, сложнее в реализации, чем Basic Authentication.
Вариант 3 неверен. OAuth 2.0 не ускоряет реализацию многофакторной аутентификации; многофакторность можно реализовать и в Basic Authentication, хотя это сложнее.
Вариант 4 верен. Главное преимущество OAuth 2.0 — это возможность делегировать ограниченный доступ к ресурсам, не передавая при этом учетные данные пользователя сторонним приложениям. Это значительно улучшает безопасность по сравнению с Basic Authentication, который предполагает передачу учетных данных с каждым запросом.
Вариант 5 неверен. OAuth 2.0 имеет более сложный процесс аутентификации, чем Basic Authentication, и использует токены доступа, а не просто сессионные токены.

Выбранный ответ:
4. Позволяет предоставлять ограниченный доступ к ресурсам без передачи учетных данных пользователя

Вопрос 4

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

Варианты ответов:

API ключи предоставляют централизованный контроль над доступом и позволяют легко отозвать права
Basic Authentication обеспечивает простой механизм передачи учетных данных, упрощая настройку доступа
OAuth 2.0 позволяет предоставлять ограниченный доступ к ресурсам без передачи учетных данных пользователя
JWT позволяет использовать долгосрочные токены для постоянного доступа без необходимости обновления
OpenID Connect фокусируется на аутентификации пользователей, обеспечивая безопасный вход и управление сессиями

Обоснование:

Вариант 1 неверен. API ключи не подходят для доступа от имени пользователя, так как они не предоставляют достаточный уровень безопасности и не реализуют авторизацию от имени пользователя.
Вариант 2 неверен. Basic Authentication передает учетные данные при каждом запросе, что не обеспечивает необходимую безопасность и не позволяет эффективно отозвать доступ.
Вариант 3 верен. OAuth 2.0 позволяет делегировать ограниченный доступ без передачи учетных данных, а также легко отзывать токены доступа в любое время, что полностью соответствует требованиям безопасности и управляемости.
Вариант 4 неверен. JWT обычно используется для передачи утверждений, но сами по себе JWT токены часто не предполагают встроенного механизма немедленного отзыва.
Вариант 5 неверен. OpenID Connect является слоем аутентификации поверх OAuth 2.0 и в большей степени предназначен для аутентификации, а не управления доступом или его отзывом.

Выбранный ответ:
3. OAuth 2.0 позволяет предоставлять ограниченный доступ к ресурсам без передачи учетных данных пользователя

Вопрос 5

Ваш API получает запрос на создание ресурса, который уже существует, и выполнение этого запроса вызывает конфликт с текущим состоянием системы. Клиент должен быть уведомлен об ошибке, чтобы понять, по каким причинам его запрос не может быть выполнен в данном контексте.
Почему в этой ситуации именно код 409 является наиболее подходящим для обработки ошибки? Потому что 409…

Варианты ответов:

Означает конфликт с существующим ресурсом, однако сервер все равно продолжает обработку, сохраняя обе версии одновременно
Сообщает о конфликте при попытке создать ресурс, который уже существует, но позволяет частично перезаписать старую версию
Указывает на конфликт с уже существующим ресурсом: создание повторной копии невозможно без изменения данных
Говорит о конфликте, когда ресурс имеет одинаковое имя, но при этом создается новая запись в базе вместо дублирования
Сигнализирует, что ресурс существует с тем же идентификатором, но сервер автоматически объединяет оба ресурса в один

Обоснование:

Вариант 1 неверен. Код 409 подразумевает, что запрос полностью отклонен, а не обработан с сохранением обеих версий.
Вариант 2 неверен. Частичное перезаписывание ресурса не предусмотрено кодом 409.
Вариант 3 верен. HTTP-код 409 Conflict предназначен именно для ситуации, когда запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса, и создание новой копии без изменения исходных данных невозможно.
Вариант 4 неверен. Код 409 не используется, если сервер при конфликте создает новую запись.
Вариант 5 неверен. Код 409 не подразумевает автоматического объединения ресурсов.

Выбранный ответ:
3. Указывает на конфликт с уже существующим ресурсом: создание повторной копии невозможно без изменения данных

Вопрос 6

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

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

Варианты ответов:

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

Обоснование:

Вариант 1 неверен. Создание новых ресурсов вместо обновления не подходит, так как не решает задачу одновременного изменения одного ресурса.
Вариант 2 технически возможен, но исключает преимущества распределенных систем и параллельной обработки, ухудшая производительность.
Вариант 3 неверен. Метод POST не является идемпотентным, и создание уникальных ключей в теле запроса не гарантирует защиты от конфликтов.
Вариант 4 верен. Использование условных заголовков (например, If-Match с ETag) с методом PUT обеспечивает проверку текущей версии ресурса перед применением изменений, эффективно предотвращая «гонки» и обеспечивая идемпотентность.
Вариант 5 неверен. Без контроля версий и состояний каждый узел сможет перезаписывать данные, что увеличит вероятность конфликтов.

Выбранный ответ:
4. Применять PUT с условными заголовками, чтобы при конфликте версий сервер отклонял повторные запросы или запросы с устаревшими данными

Вопрос 7

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

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

Варианты ответов:

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

Обоснование:

Вариант 1 неверен. Кэширование не влияет на саму идемпотентность выполнения запроса, а только на отображение данных пользователю.
Вариант 2 неверен. PUT по своей спецификации требует наличие уникального идентификатора ресурса, иначе это не PUT, а POST.
Вариант 3 неверен. Метод PUT по определению поддерживает повторные (идемпотентные) запросы, независимо от массовости обновления.
Вариант 4 неверен. Некорректная обработка заголовка Content-Type не связана напрямую с нарушением идемпотентности; это лишь вызовет ошибки обработки запроса.
Вариант 5 верен. Одновременная (параллельная) обработка PUT-запросов может привести к состоянию гонки и вызвать несогласованность данных, тем самым нарушая принцип идемпотентности.

Выбранный ответ:
5. Параллельная обработка PUT-запросов, вызывающая несогласованность данных

Вопрос 8

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

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

Варианты ответов:

Установить для дочерних записей статус "без родителя"
Реализовать проверку зависимых данных перед удалением
Переключить метод DELETE на PATCH, чтобы обновлять статус записей
Настроить каскадное удаление для связанных ресурсов
Переключиться на пометку заказов как удаленных, без их физического удаления

Обоснование:

Вариант 1 неверен. Установка статуса "без родителя" не решает проблему целостности данных, а может лишь ухудшить её.
Вариант 2 неверен. Простая проверка зависимых данных сама по себе не решает проблему целостности, если требуется именно удаление зависимых ресурсов.
Вариант 3 неверен. Использование метода PATCH вместо DELETE может быть полезно для "мягкого" удаления, но напрямую не гарантирует целостность связей при фактическом удалении.
Вариант 4 верен. Каскадное удаление предназначено специально для поддержания целостности данных при удалении родительских записей и гарантирует удаление всех связанных дочерних ресурсов.
Вариант 5 неверен. Отметка о том, что ресурс удален, не решает вопрос с целостностью зависимых данных, так как ресурсы продолжают существовать и могут вызывать конфликты.

Выбранный ответ:
4. Настроить каскадное удаление для связанных ресурсов

Вопрос 9

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

Варианты ответов:

Использовать кэширование для массовой рассылки уведомлений
Использовать Webhooks вместо WebSocket для массовой рассылки уведомлений
Применить шардирование уведомлений на основе уникальных идентификаторов
Разделить сервер на несколько экземпляров и использовать балансировщик нагрузки
Применить брокер сообщений (например, RabbitMQ, Kafka) для асинхронного управления уведомлениями

Обоснование:

Вариант 1 не решает фундаментальную проблему высокой нагрузки и не обеспечивает масштабирование, так как просто меняет механизм связи, не влияя на нагрузку.
Вариант 2. Webhooks не заменяют WebSocket, а подходят для других сценариев (push-уведомлений с сервера на сервер).
Вариант 3 не является подходящим решением для снижения нагрузки от реального времени на большой аудитории, так как не решает проблему массовых подключений.
Вариант 4 частично решает проблему доступности, но не устраняет проблему с масштабируемостью активных WebSocket-соединений.
Вариант 5 является верным, так как брокер сообщений обеспечивает масштабируемость и асинхронное распределение нагрузки на уведомления. Это позволяет значительно снизить нагрузку на сервер, эффективно управлять сообщениями и обеспечивать стабильность системы при большом числе клиентов.

Выбранный ответ:
5. Применить брокер сообщений (например, RabbitMQ, Kafka) для асинхронного управления уведомлениями

Вопрос 10

Вы разрабатываете высоконагруженное GraphQL API для приложения обмена сообщениями, где требуется мгновенные уведомления об обновлениях и статусах пользователей (онлайн/офлайн). При этом клиенты ограничены в ресурсах и не могут часто отправлять серверу постоянные запросы Query из-за увеличения нагрузки. Нужно обеспечить реальное время (real-time) получения данных, сохранив при этом гибкость и масштабируемость сервиса.

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

Варианты ответов:

Resolver в GraphQL
Directive в GraphQL
Mutation в GraphQL
Subscription в GraphQL
Query в GraphQL

Обоснование:

Вариант 1 (Resolver) неверен. Resolver — это функция, которая получает данные для определенного поля; он не связан напрямую с организацией real-time связи.
Вариант 2 неверен. Directive (директивы) используются для управления поведением выполнения запроса и схемы, но не для real-time коммуникации.
Вариант 3 (Mutation) неверен, так как Mutation используется для изменения данных, а не для передачи данных в режиме реального времени.
Вариант 4 (Subscription) является верным, поскольку именно этот механизм в GraphQL предназначен для организации подписки клиента на события, предоставляя обновления в реальном времени.
Вариант 5 (Resolver) неверен, так как resolver отвечает за получение данных для полей и не обеспечивает real-time двунаправленную связь.

Выбранный ответ: Subscription в GraphQL

Вопрос 10

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

Использование аннотаций кода для автоматической генерации спецификаций OpenAPI.
Автоматическая генерация документации на основе тестов API (contract testing).
Наличие пользовательского интерфейса (UI), отображающего состояние API в реальном времени.
Поддержка нескольких версий спецификаций API с помощью инструментов версионирования.
Автоматическое преобразование спецификаций OpenAPI в SDK для различных языков программирования.

Какие или какой из этих факторов (1–5) наиболее эффективно помогут минимизировать технический долг и упростить поддержку документации?

Варианты ответов:

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

Обоснование:

Фактор 1 (аннотации) непосредственно связан с генерацией актуальной документации на основе реального кода, помогая избежать технического долга, так как документация всегда соответствует коду.
Фактор 2 (contract testing) также помогает минимизировать технический долг, обеспечивая синхронизацию спецификации и реального поведения API.
Фактор 3 (наличие UI для отображения состояния API) сам по себе не обязательно минимизирует технический долг в коде или документации; он скорее улучшает UX, но не решает проблему синхронизации и поддержки документации.
Фактор 4 (поддержка нескольких версий спецификации API) важен, но может усложнить документацию и увеличить технический долг, если не контролируется строго.
Фактор 5 (генерация SDK) полезен, но является следствием качественно реализованных первых двух факторов и сам по себе не минимизирует технический долг непосредственно в документации и спецификации.

Наиболее эффективно технический долг минимизируется, если спецификация и документация генерируются автоматически на основании кода и тестов (факторы 1 и 2). Это обеспечивает актуальность, снижает риск человеческой ошибки и упрощает поддержку документации.

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

Вопрос 11

Ваш API должен быть совместим с клиентами, которые работают с различными форматами данных (XML и JSON). Клиенты должны иметь возможность выбирать предпочитаемый формат ответа с минимальными изменениями в коде, нужно учесть REST-подход и оптимальную поддержку контент-негациации.

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

Варианты ответов:

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

Обоснование:

Вариант 1 неверен. Использование IP-адресов для определения формата ответа ненадежно и не соответствует REST-принципам.
Вариант 2 возможен, но не оптимален, так как это увеличивает количество вариантов конечных точек и усложняет API.
Вариант 3 является верным и оптимальным. Использование заголовка Accept – это стандартный RESTful-подход (контент-негациация), позволяющий клиенту указывать предпочитаемый формат данных без изменения самого запроса или URL.
Вариант 4 (параметр query) также технически допустим, но менее предпочтителен с точки зрения стандарта REST и семантики.
Вариант с физическим разделением API по форматам отсутствует в текущем изображении и не является хорошей практикой.

Правильный ответ:
3. Использовать заголовок Accept в HTTP-запросе

Вопрос 12

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

Варианты ответов:

Использовать один общий токен без срока действия для всех пользователей, которые его применяют
Использовать токены без срока действия, но регулярно обновлять их вручную на сервере
Устанавливать короткий срок действия токена доступа (access token) и использовать refresh-токены для его продления
Хранить время жизни токена на стороне клиента и вручную продлевать токены по необходимости
Использовать токены с максимально длительным сроком действия и не выполнять их отзыв

Обоснование:

Вариант 1 неверен, так как использование единого токена для всех пользователей без срока действия является крайне небезопасным решением.
Вариант 2 неверен. Отсутствие срока действия (бессрочные токены) существенно снижает безопасность.
Вариант 3 верен. Использование access-токенов с коротким сроком действия и refresh-токенов для их регулярного обновления является стандартной практикой, обеспечивающей баланс безопасности и удобства.
Вариант 4 (срок действия максимально длинный без отзыва) неверен, так как это создаёт риски безопасности.
Вариант 5 (хранение времени жизни токена на клиенте с ручным продлением) также неверен, так как клиентское управление сроками действия токена создает дополнительные риски и неудобства.

Выбранный ответ: Использовать токены с ограниченным сроком действия и refresh-токены для продления сеанса.

Вопрос 13

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

Некоторые параметры никогда не используются.
Некоторые параметры используются очень редко и усложняют логику API.
Обновления функциональности замедляются из-за сложности поддержки всех параметров.

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

Варианты ответов:

Создать отдельный API Gateway для маршрутизации запросов к упрощенным и сложным версиям конечных точек
Объединить функции в отдельные модули и использовать балансировщик нагрузки
Реализовать универсальную конечную точку с поддержкой выборочных параметров, чтобы сократить количество конечных точек
Удалить неиспользуемые параметры и реорганизовать логику конечных точек, сохранив редкие параметры через feature flags
Удалить неиспользуемые параметры и оставить только минимально необходимые конечные точки

Обоснование:

Вариант 1 не оптимален, так как добавление API Gateway лишь усложнит архитектуру, а не решит проблему большого количества редко используемых параметров.
Вариант 2 не решает вопрос с множеством параметров, так как просто разделение на модули и балансировка нагрузки не изменит фактическую сложность обработки.
Вариант 3 (Универсальная точка) не представлен явно, однако он присутствует на исходном изображении. Если подразумевается универсальная конечная точка с поддержкой выборочных параметров, то это подход, снижающий количество точек, но не уменьшающий сложность самих параметров.
Вариант 4 является верным подходом, так как предполагает удаление неиспользуемых параметров и применение feature flags для управления редко используемыми функциями, что упростит API, сохранив совместимость и улучшив производительность.
Вариант 5 не оптимален, так как удаление параметров и конечных точек может привести к проблемам совместимости с текущими клиентами.

Выбранный ответ:
4. Удалить неиспользуемые параметры и реорганизовать логику конечных точек, сохранив редкие параметры через feature flags

Вопрос 14

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

Идентифицировать клиентов (например, с помощью токенов).
Создать разные правила для различных клиентов (например, VIP-клиенты).
Мгновенно блокировать клиентов при превышении лимита.

Какой подход будет оптимальным?

Варианты ответов:

Только блокировать клиентов, превышающих лимиты, без дополнительных условий
Использовать кэширование запросов для уменьшения нагрузки
Добавить отдельные правила только для VIP-клиентов через API Gateway
Сформировать функцию rate-limiting с динамическими лимитами, привязанными к идентификаторам клиентов
Ограничить доступ к API для всех клиентов, кроме заранее определенных групп

Обоснование:

Вариант 1 не является оптимальным, так как не предусматривает гибкость и не учитывает разные условия клиентов.
Вариант 2 неверен. Кэширование помогает снизить нагрузку, но не решает проблему частых запросов, требующих уникальной обработки.
Вариант 3 неверен, так как создание отдельного правила только для VIP-клиентов не решает полностью проблему гибкости и масштабируемости для всех клиентов.
Вариант 4 верный и оптимальный, так как он позволяет настроить индивидуальные лимиты (rate-limiting) с учетом идентификаторов клиентов и позволяет эффективно управлять нагрузкой, а также быстро реагировать на ситуации с перегрузкой.
Вариант 5 («ограничить доступ для всех, кроме заранее определенных групп») не является оптимальным, так как слишком жестко ограничивает доступ.

Выбранный ответ:
4. Сформировать функцию rate-limiting с динамическими лимитами, привязанными к идентификаторам клиентов

Вопрос 15

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

Варианты ответов:

Создать отдельный API Gateway для маршрутизации запросов к упрощенным и сложным версиям конечных точек
Объединить функции в отдельные модули и использовать их для генерации конечных точек динамически
Внедрить кэширование запросов и уменьшить использование серверных ресурсов, не меняя структуру API
Реализовать универсальную конечную точку с поддержкой выборочных параметров, чтобы сократить количество конечных точек
Удалить неиспользуемые параметры и реорганизовать логику конечных точек, сохранив редкие параметры через feature flags

Обоснование:

Вариант 1 усложнит архитектуру, так как добавит ещё один слой (Gateway), не решив проблему параметров напрямую.
Вариант 2 полезен с точки зрения организации кода, но динамическая генерация конечных точек не избавит от проблемы лишних параметров.
Вариант 3 поможет только с нагрузкой на сервер, но не улучшит сложность API и не повлияет на параметры.
Вариант 4 (универсальная конечная точка) может упростить количество конечных точек, но сделает их более сложными для понимания и использования.
Вариант 5 является оптимальным: удаление неиспользуемых параметров упрощает API, а редкие параметры можно сохранить и управлять их доступностью через feature flags. Это позволяет максимально сохранить совместимость и упростить поддержку.

Выбранный ответ:
5. Удалить неиспользуемые параметры и реорганизовать логику конечных точек, сохранив редкие параметры через feature flags

Заключение

Подобные тестирования — это отличный способ отрефлексировать собственный опыт и знания. Ты словно сверяешь часы со стандартами индустрии, уточняешь, на правильном ли ты пути, и что ещё стоит подтянуть.

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