Тонкий или толстый REST-клиент?

Question

У нас есть мобильное приложение, которое принимает данные от сервера (REST API)

Есть два способа:

• /v1/фильмы (возвращает фильмы: идентификатор, название, IMAGE_URL ...)
• /v1/likes (возвращает фильмы id, который нравится пользователю)

Мобильное приложение имеет вид «Мои предпочтения», который содержит фильмы, которые нравятся пользователям, и этот вид также должен содержать необходимые метаданные (id, title, image_url .. .)

Я вижу несколько решений:

1. Возвращение больше информации о фильмах в методе «/ нравится /»
2. Создать новый метод «/ фильмы/любит /»
3. Мобильное приложение должно сделать 2 запросов ,

Я знаю, это выбор между гибкостью и скоростью. Где граница, когда приложение становится тонким клиентом вместо толстого?

Answer 1

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

Take a look at HAL. HAL предоставляет представление запрошенного ресурса, а также некоторые метаданные, которые включают в себя URI других ресурсов, с которыми он связан (_links), и позволяет полностью копировать эти другие ресурсы с помощью ответа (_embedded) ,

Это дает вам максимальный взлет для каждого запроса, пока мы не получим HTTP/2.0, который позволит использовать несколько запросов.

Я не использую термины «тонкий» и «толстый» клиент. Каждая строка кода делает ее немного толще, и нет границы, определяющей два.