Что хотят услышать интервьюеры:

REST не стал «менее популярным» в целом, но в современных приложениях его часто заменяют более удобными подходами там, где нужен гибкий контракт и высокая производительность. Обычно ожидают услышать, что REST ограничивает работу с данными fixed-endpoint’ами и часто приводит к overfetching/underfetching. Ещё важны слабая гибкость для клиентских запросов и рост сложности при большом числе ресурсов и версий API.

Определение:

REST — это архитектурный стиль построения HTTP API, где ресурсы доступны через стандартные методы и понятные URL. Его основная сила — простота, кэширование и универсальность.
Снижение популярности в некоторых сценариях связано не с тем, что REST плох, а с тем, что для сложных клиентских приложений он не всегда удобен: клиент получает либо слишком много данных, либо недостаточно, и вынужден делать несколько запросов.

Пример использования:

Например, мобильному приложению нужно показать карточку пользователя с именем, аватаром, последними 5 заказами и статусом подписки. В REST это часто превращается в несколько запросов к разным эндпоинтам или в один «толстый» ответ, который возвращает лишние данные. В таких случаях иногда выбирают GraphQL или BFF-подход.

// Упрощённый пример REST-контроллера
@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping("/{id}")
    public UserDto getUser(@PathVariable Long id) {
        return userService.findUserDtoById(id);
    }

    @GetMapping("/{id}/orders")
    public List<OrderDto> getUserOrders(@PathVariable Long id) {
        return orderService.findLastOrdersByUserId(id);
    }
}

Пояснение кода:

В этом примере REST API разделяет данные по ресурсам: пользователь и его заказы — это разные эндпоинты.
Если клиенту нужна только часть полей пользователя, он всё равно может получить больше данных, чем требуется.
Если нужны данные из нескольких ресурсов сразу, придётся делать несколько HTTP-запросов.
Именно это и показывает типичную проблему REST в современных UI-приложениях: ограниченная гибкость ответа под конкретный экран.

Ключевые моменты:

REST остаётся популярным, но не всегда оптимален для сложных клиентских интерфейсов.
Главная проблема — overfetching и underfetching данных.
Часто требуется несколько запросов для одного экрана или страницы.
Версионирование и поддержка большого числа ресурсов могут усложнять API.
Для некоторых задач удобнее GraphQL, gRPC или BFF.
REST хорошо подходит там, где важны простота, стандартность и HTTP-кэширование.

Какие причины делают использование REST менее популярным в современных приложениях?