Зачем выравнивать ответы API в приложении Node?

Question

Меня попросили взглянуть на сглаживание ответов API для проекта Node.js, над которым я работаю, но я не совсем уверен, почему его нужно сглаживать.Никакие ответы не вложены за 2 уровня, так что для меня это не так уж плохо.Кто-нибудь может сказать мне, почему ответ API был сглажен?Я хотел бы узнать плюсы и минусы, а также услышать какие-либо предложения о том, как это сделать?Я сейчас смотрю на пакет npm flat.

Вот пример ответа:

{
    "users": [
        {
           "id": 1,
           "name": "John Doe",
           "email": "john@doe.com",
           "suppliers": [
               {
                   "id": 1,
                   "name": "Supplier1",
               }
           ]
       },
       {
           "id": 2,
           "name": "Jane Doe",
           "email": "jane@doe.com",
           "suppliers": [
               {
                   "id": 1,
                   "name": "Supplier1",
               },{
                   "id": 2,
                   "name": "Supplier2",
               }
           ]
       }
    ]
}

Answer 1

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

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

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

Считайте, что ваши данные сведены в этих двух подходах:

Сглаженный подход # 1

{
    "users": [
        {
           "id": 1,
           "name": "John Doe",
           "email": "john@doe.com",
           "suppliers_1_id": 1,
           "suppliers_1_name": "Supplier1",
           "suppliers_2_id": null,
           "suppliers_2_name": null
        }, {            
           "id": 2,
           "name": "Jane Doe",
           "email": "jane@doe.com",
           "suppliers_1_id": 1,
           "suppliers_1_name": "Supplier1",
           "suppliers_2_id": 2,
           "suppliers_2_name": "Supplier2"               
       }
    ]
}

В этом примере решение должно быть решено заранеевремени, какое максимальное количество поставщиков, которые могут быть возвращены.Мне действительно не нравится такой дизайн для хранения данных, но часто это запрашиваемый способ отображения данных в таблице.Например, если для пользователя есть 3 поставщика, вы не сможете вернуть эти данные без добавления дополнительных столбцов.Это очень быстро становится неуправляемым, если у вас нет очень маленького и конечного максимального числа дочерних строк.

Сглаженный подход # 2

{
    "users": [
        {
           "id": 1,
           "name": "John Doe",
           "email": "john@doe.com",
           "supplier_id": 1,
           "supplier_name": "Supplier1"
       }, {     
           "id": 2,
           "name": "Jane Doe",
           "email": "jane@doe.com",
           "supplier_id": 1,
           "supplier_name": "Supplier1"        
       }, {     
           "id": 2,
           "name": "Jane Doe",
           "email": "jane@doe.com",
           "supplier_id": 2,
           "supplier_name": "Supplier2"               
       }
    ]
}

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

Я не совсем уверен, почему этонужно выровнять.

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