Специализация
Python Backend Developer
Java Backend Developer
Node.js Backend Developer
Golang Backend Developer
React Frontend Developer
Выберите навыки
React
JavaScript
Git
Redux
Webpack
Сложность
1-3
4-6
7-8
9-10
Рейтинг вопросов
1
2
3
4
5
Подпишись на React Developer в телеграм
Как организовывалось взаимодействие между микросервисами (REST API, брокеры сообщений)?
Для синхронных операций использовали REST/gRPC: сервисы запрашивали данные друг у друга по HTTP или HTTP/2. Для асинхронных процессов — RabbitMQ или Kafka: публиковали события (OrderCreated) и слушали клиенты. REST подходит для прямых запросов с ожиданием ответа, брокеры — для фоновых задач, рассылок и обеспечения eventual consistency.
Чем асинхронное взаимодействие через Kafka отличается от синхронного через REST API?
REST API — синхронный запрос/ответ, клиент ждёт ответа от сервера и блокируется. Kafka — асинхронная передача сообщений: продюсер отправляет событие и продолжает работу, потребитель читает в своём темпе. Асинхронность снижает связанность и повышает отказоустойчивость.
Какие ограничения и недостатки есть у REST API?
REST ограничен HTTP-протоколом, плохо подходит для real-time, не имеет строгой спецификации, может приводить к избыточным запросам и сложной версионности. Не оптимален для сложных или связных данных.
Что такое API? Чем REST API отличается от других типов API?
API (Application Programming Interface) — набор правил для взаимодействия программ. REST API использует HTTP-методы (GET/POST) и стандартные форматы данных (JSON). Отличается от SOAP (строгий XML-протокол) простотой, а от GraphQL — отсутствием гибкости в запросах. Например, REST требует чётких эндпоинтов (/api/users), а GraphQL позволяет клиенту запрашивать нужные поля.
В чём разница между POST (создание) и PUT (обновление) в REST API?
POST - создание ресурса (сервер назначает ID)
PUT - полное обновление ресурса (идемпотентный)
PATCH - частичное обновление
Как организовать идемпотентный REST API, чтобы повторный запрос клиента не привёл к дублированию операции?
Чем технология WebSockets концептуально отличается от REST API или общения через брокер сообщений?
Какой протокол лежит в основе REST API и может ли использоваться в SOAP?
Какие основные методы HTTP используются в REST API и каково их назначение?
Какие существуют альтернативы REST API и в чём их ключевые особенности?
Рейтинг:
4
Сложность:
7
Идемпотентность достигается введением уникального идентификатора запроса (Idempotency-Key). Сервер сохраняет этот ключ и результат операции, и при повторном запросе возвращает тот же результат без повторного выполнения.
Рейтинг:
4
Сложность:
6
WebSockets создают постоянное двустороннее соединение для обмена данными в реальном времени. REST API — это цикл "запрос-ответ", где соединение закрывается после каждого обмена. Брокер сообщений (например, RabbitMQ) выступает асинхронным посредником, позволяя сервисам общаться, не будучи подключенными напрямую и в одно и то же время. WebSockets — это "живой канал", REST — "отдельные звонки", а брокер — "система почтовых ящиков".
Рейтинг:
4
Сложность:
6
В основе REST API лежит протокол HTTP (HTTPS). REST — это архитектурный стиль, который напрямую и максимально полно использует возможности HTTP: методы (GET, POST), коды состояния (200, 404), заголовки и URI. Без HTTP классический REST невозможен.
SOAP может использовать HTTP, но не ограничивается им. HTTP для SOAP — это просто один из возможных транспортных протоколов для передачи XML-сообщений. SOAP также может работать поверх SMTP (email), TCP или даже JMS (очереди сообщений). При этом SOAP не использует семантику HTTP так, как это делает REST.
Рейтинг:
5
Сложность:
3
Основные методы HTTP (или "глаголы") определяют тип операции, которую клиент хочет выполнить с ресурсом. GET используется для безопасного получения данных с сервера, не изменяя их. POST служит для создания нового ресурса или отправки данных на обработку. PUT применяется для полного обновления существующего ресурса, а PATCH — для его частичного обновления. DELETE, как следует из названия, удаляет ресурс. Эти методы придают API единообразную и понятную структуру.
Рейтинг:
4
Сложность:
7
Основные альтернативы: GraphQL позволяет клиенту запрашивать именно те данные и поля, которые нужны, одним запросом, решая проблемы over/under-fetching. gRPC — это высокопроизводительный фреймворк для вызова методов между сервисами, использующий бинарный протокол и HTTP/2. WebSockets обеспечивают постоянное двустороннее соединение для данных в реальном времени. SOAP — это старый, но строго стандартизированный протокол для enterprise-интеграций с встроенной безопасностью. Выбор зависит от задачи: клиентская эффективность (GraphQL), внутренняя производительность (gRPC), реальное время (WebSockets) или строгие корпоративные стандарты (SOAP).
Рейтинг:
2
Сложность:
8
Рейтинг:
2
Сложность:
6
Рейтинг:
2
Сложность:
6
Рейтинг:
2
Сложность:
6
Рейтинг:
1
Сложность:
5
