REST API дизайн для получения резюме и деталей

Question

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

У меня есть экран с подробной информацией, который отображает больше информации, такой как класс, количество учеников, информация о учениках в классе и т. Д. c.

Какова наилучшая практика для разработки такого API для потребления с помощью пользовательского интерфейса - можно ли назвать его как / summary, / details API? или следуйте соглашению REST и назовите его как / class (GET class details) и передайте соответствующие фильтры для получения сводки против подробностей, т.е. / class? filter = summary | details

, пожалуйста, сообщите.

Answer 1

Оба подхода хороши в качестве конечных точек REST.

Да, типично иметь мелкозернистые ресурсы, которые описывают конкретные вещи c, но также приемлемо создание пользовательских конечных точек, которые оптимизируются для очень специфических c прецеденты.

Фактически, одна конечная точка, которая имеет все соответствующие состояния и описывает все возможные действия, которые пользователь может выполнить из этого состояния, может считаться более RESTful, если вы следуете первоначальной идее Academi c REST против общего понимания того, что такое REST.

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

Tl; dr: либо, вероятно, в порядке и имеют соотношение цена / качество.