Проектирование REST - сохранение большого набора связанных объектов

Question

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

Мне нужно разработать REST API, который позволит загружать и редактировать список почтовых индексов продаж.

В принципе у меня есть 2 варианта:

1) создает 2 Ресурсы: Продажи и SalesZip. Отправьте данные о продажах и затем запишите записи SalesZip для каждого поддерживаемого почтового индекса.

2) Создать объект продаж, и список загрузки поддерживаемых почтовых индексов, как это:

{ 
    id : 1, 
    name : "John", 
    zip : [ 
     "90231", 
     "12341", 
     ... 
    ] 
} 

и отправить почтовые индексы, как массив:

zip[]=90231,12341 

Оба способа имеют некоторые недостатки.

Если вы используете первый вариант, мне может потребоваться отправить слишком много отдельных HTTP-запросов. Если вы используете второй вариант, мне может потребоваться отправить довольно большой запрос PUT/POST.

Вопрос

Какой вариант использовать? Что лучше всего подходит для проектирования таких функций?

Answer 1

Что такое «довольно большой»?

В приблизительной оценке, если каждый символ имеет 2 байта, а ваши почтовые индексы имеют 5 символов, каждый код составляет 10 байт. Предполагая, что US has 41,741 ZIP codes, в худшем случае в США, продавец, который продает по всей стране, нуждается в полезной нагрузке около 417 410 байт или 407,6 килобайта.

В среднем, сколько почтовых индексов принадлежит продавцу? как он распространяется? Как часто вы получаете эти запросы? Вы можете обнаружить, что это не так уж плохо.

Недостаточно данных для принятия решения, но, похоже, второй вариант не является плохим.