бизнес-логики и успокоительной API дизайн

Question

Давайте предположим, что у нас есть простой API, позволяющий клиентам получать список элементов определенного типа:

GET /items/foo 
    GET /items/bar 
    GET /items/blah 

Ответ представляет собой список элементов запрашиваемого типа, каждая запись имеет уникальный идентификатор. Клиент обычно отображает эти элементы в таблице/сетке/и т. Д.

Теперь в клиенте мы должны реализовать функцию закрепления, так что другой API позволяет фиксировать/снимать элементы на основе их идентификатора & их типа. Поэтому я обсуждал с коллегами возможности информировать клиента о том, какие предметы закреплены или нет.

Опция должна была иметь другой API GET /pinning/{type}, чтобы вернуть список всех закрепленных элементов указанного типа.

Другим решением было использовать аналогичный API GET /pinning/{type}, чтобы вернуть список идентификаторов всех закрепленных элементов. Позвольте клиенту разобраться.

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

Какое решение лучше? Или какие другие решения возможны?

Answer 1

Если сервер вернет ItemIds только в GET /pinning/{type}, клиент должен будет многократно называть что-то вроде GET /items/{itemId}, чтобы получить данные, которые он может отображать в пользовательском интерфейсе, не так ли? Это, в свою очередь, просто увеличит нагрузку на сервер. Если идентификатора будет достаточно, вы, вероятно, можете уйти с предлагаемым решением. Поскольку и клиент, и сервер, похоже, находятся под одним и тем же зонтиком (как в вашей компании также является потребителем API), у вас достаточно информации для принятия решения.

Даже если бы это был публичный API с большим количеством клиентов, я бы по-прежнему шел по пути возврата элементов, а не только itemIds - возможно, в постраничной форме по соображениям производительности.