REST API: поля объектов в списке объектов в ответ JSON

Question

Предположим, мы создаем одностраничное приложение с двумя видами: просмотр списка и подробный вид.

В представлении списка мы представляем список объектов с их именами и, возможно, более минимальными данными.

В подробном представлении мы представляем все возможные поля конкретного объекта.

Отсюда вопрос: когда мы ПОЛУЧИТЬ /api/items/, мы должны или не должны в JSON-кодирования все поля объектов в списке, или только те, которые представлены в списке?

Другими словами, если мы покажем, список продуктов, как

Name  Price 
Potato 1 
Milk  2 

делает наш API должны реагировать с JSON как это:

{ 
    [ 
     { 
      "name": "Potato", 
      "quantity": "1 kg", 
      "origin": "Egypt", 
      "manufacturer": "Egypt Farmers", 
      "price": 1, 
      "packaging": "String bag", 
      "_type": "Food" 
     }, 
     { 
      "name": "Milk", 
      "quantity": "1 litre", 
      "origin": "Finland", 
      "manufacturer": "Valio", 
      "price": 2, 
      "packaging": "Tetra Pak", 
      "_type": "Food" 
     }, 
    ] 
} 

или как это:

{ 
    [ 
     { 
      "name": "Potato", 
      "price": 1, 
      "_type": "Food" 
     }, 
     { 
      "name": "Milk", 
      "price": 2, 
      "_type": "Food" 
     }, 
    ] 
} 

Answer 1

Ответ, как обычно, может быть: все зависит от того,)

1. В случае соединения ограничен или неустойчивый (например, мобильная связь, как LTE или даже WiFi) лучшая идея заключается в том, чтобы вернуть все список ресурсов со всеми заполненными полями и использовать те же данные для обоих представлений. В компании, в которой я работаю, мы часто применяем этот подход, поскольку наши бэкэнд почти всегда предоставляют данные для мобильных приложений.

2. Вторая идея - использовать механизм, называемый расширением поля или ресурса. В общем случае запрос к конечной точке и области ресурсов, которые будут возвращены, включены в этот запрос:

   /api/items?fields=(name, quantity, origin, whatever) 
   

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

3. Лично я бы использовал две конечные точки.Конечная точка /api/items/ с встроенным механизмом расширения поля/ресурса (с ограниченным списком полей, который может быть расширен), а второй /api/items/{itemID}/ для возврата определенного элемента со всеми данными. Это также самый подход RESTful.

Answer 2

API RESTful должен сосредоточиться на представленных ресурсах, не обязательно, как эти ресурсы используются.

В сценарии «главный/подробный» мастер обычно содержит сведения об основном объекте и включает в себя список его деталей (включая ссылку на API для каждого подробного ресурса. Так/api/items/может выглядеть как это:

{ 
    items: [ 
     { name: 'item 1', href: '/api/items/1' }, 
     { name: 'item 2', href: '/api/items/2' } 
    ] 
} 

ресурс деталь будет содержать свойства отдельного элемента в списке элементов Таким образом,/апи/пункты/{ITEMNAME} апи может выглядеть следующим образом:.

{ 
    name: 'item 1', 
    color: 'blue', 
    weight: 100, 
    id: '/api/items/1' 
} 

Так что это будет вероятно, ближе всего к вашему второму сценарию. Существует ряд преимуществ es к этой модели: он, вероятно, соответствует модели домена, к которой обращается ваш api, делает каждый api очень простым и одноцелевым, его легко масштабировать даже в очень больших списках. Недостатком является то, что это может привести к большей сложности для клиента.