Управление API и лучшие практики

Question

Пытаясь получить мнение эксперта и направление:

Мы изучаем некоторые из наших RestAPI нашими клиентами, чтобы получить данные и создать базы данных в конце. Некоторые используют sql, некоторые nosql datastores.

Как мы должны проектировать конечные точки? Большие объекты со встроенными ссылочными объектами или отдельными конечными точками для отдельных объектов? А как насчет ссылок? Есть ли какие-то передовые практики, о которых следует помнить, пока мы смотрим на схемы?

Примеры: Фильм имеет изображения В фильме есть похожие фильмы В фильмах также есть актеры

Кроме того, как я могу оценивать, имеет ли смысл новая конечная точка или лучше встраивать объекты в существующую конечную точку?

Любопытно услышать некоторые мысли и рассуждения.

Answer 1

Фундаментальный вопрос: вы всегда будете запрашивать полный набор данных (изображения, похожие фильмы, актеры и т. Д.) Или вы хотите иметь выбор, чтобы получить только часть этого? Второй вопрос: насколько перекрываются наборы данных? (актер может сыграть в> 100 фильмах, и получение его информации как части информации о каждом фильме бессмысленно)

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

Если вы хотите иметь больше гибкости, лучше использовать отдельные конечные точки. Это вызовет больше сетевого трафика. Если вы выберете этот подход, вам следует рассмотреть возможность использования какого-либо кеша.

С другой стороны, вы можете создать гибрид, который возвращает базовую информацию для /movie, но расширенные данные для /movie?include=images,cast и /movie?include=all. Но это потребует дополнительных разработок.

Там также может быть четвертый вариант. Вы слышали о GraphQL (https://graphql.org/)? Это позволяет определить, какие данные вы хотите получить.