REST API Design: как разбить объект API, чтобы сделать более масштабируемый и надежный API

Question

У нас есть сайты электронной коммерции для мобильных телефонов. Мы создаем спокойные api для POST, PUT, DELETE, UPDATE мобильных телефонов.

Каждый мобильный телефон будет иметь следующие основные функции: - цена, производитель, год выпуска, цвет, скидка.

Наряду с этим, большинство мобильных телефонов тоже будут иметь изображения.

Кроме того, некоторые из них имеют гарантию производителя. Скажем, 50% из них.

И у немногих мобильных телефонов будут доступные варианты финансирования, например, у нас есть определенные банки, чтобы облегчить им кредит. Почти 80% будут иметь этот объект.

Мы решали два подхода для разработки API для этого:

подход 1. Все из них в тот же объект JSON. Только один API:

{ 
    "basicInfo": { 
     "price": "", 
     "mfgYear": "", 
     "manufacturer": "" 
    ... 
    }, 
    "images":{...}, 
    "warranty":{...},  
    "finance":{...}  
    } 

Подход 2. У всех этих объектов JSON отдельно. Например:

First Api for "basicInfo". 
    Second Api for "images". 
    Third Api for "warranty". 
    Fourth Api for "finance" 

я мог понять некоторые плюсы и минусы каждого из них:

APPROACH1: Плюсы: Мы получаем всю информацию о наличии вместе на сервере. Это означает, что меньше обращений API, меньше нагрузки на сервер. Кроме того, в будущем, если мы реализуем некоторую обработку очереди для сохранения этой информации о запасах в базу данных, не было бы случая, когда изображение/гарантия/финансирование публикуются до того, как фон будет вставлен в базу данных, так как мы все вместе сообщаем здесь. Поэтому мы сначала вставим данные в базу данных, а затем добавим запись в другие таблицы, которые будут иметь отношения с внешним ключом. Против: Этот API/ресурс имеет множество обязанностей. Он станет все больше и больше, и в будущем в этом API может быть слишком много полей. Также это похоже на нарушение принципа Single Responsibility для меня.

ПОДХОД 2: Плюсы: Это выглядит немного чище и организовано. Похоже, что каждый API имеет свою собственную ответственность. Выглядит масштабируемо для меня. Если изменения производятся в одном API, это менее вероятно повлияет на другие API. Против: Больше количества обращений API на сервере. Выделяются больше шансов на то, что зависимые ресурсы акций будут размещены перед запасом. Например, мы можем деактивировать изображения перед вставкой.

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

Каков наилучший подход, то есть более спокойный, масштабируемый и улучшенный показатель производительности?

Answer 1

Учитывая только предоставленную вами информацию, я хотел бы посмотреть, как я буду разрабатывать эту систему. Имеют отдельные конечные точки для телефонов, гарантии и информацию о финансировании. Агрессивно кэшируйте гарантии, потому что они редко меняются. Включите ссылки на информацию о гарантии и финансировании в представлении JSON телефона. Пусть конечная точка /phones/{phoneId} поддерживает параметр запроса с именем «развернуть».Если сервер видит expand=warranty, expand=financing или expand=warranty, financing, добавьте соответствующий JSON в ресурс телефона в дополнение к предоставлению ссылок. Теперь клиенты могут выбрать, какую информацию они нуждаются и получить.

Для изображений, если возможно, используйте CDN, чтобы позаботиться о них и просто включите ссылку. Если вам нужно управлять ими в своем API, я бы относился к ним так же, как и к гарантии и финансированию выше. Убедитесь, что они очень агрессивно кэшированы, потому что то, что выглядит на экране телефона, не будет меняться очень часто. Если вам нужно изменить изображение, используйте новое имя файла.

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

Наконец, обратите внимание, что открытые вопросы, подобные этому, более подходят для https://softwareengineering.stackexchange.com/. Переполнение стека предназначено для вопросов с правильным ответом.

Answer 2

Я не профессионал с JSON, но AFAIK можно складывать эти объекты, чтобы вы могли иметь иерархическое (полное) нажатие на вставки/обновления, а также полные (или предполагаемые неполные) вызовы.

Таким образом, вам не нужно взорвать каждое действие при нажатии и вытягивании и по-прежнему гибки, когда речь идет о расширениях. Вы также можете - или, скорее всего, захотите - вызвать специализированные процедуры для вставки/обновления каждого из под-объектов, чтобы вы могли предоставить и использовать их как часть REST API.

Для тяги вы можете либо отметить отсутствующие узлы как undecided, либо уже проверить на БД и отметить как unloaded или not available.

Просто имейте в виду, что если вы предоставляете API для всех подзадач объектов (пр.1 или 3) она всегда будет вызывающему абоненту иметь те вызовы sorted-, особенно когда речь идет о делеции, которые, как правило, выполняются в обратном порядке.

Если вы решите пойти на комплексный API (1 или 3), вы можете - однако - по-прежнему работать с очередями и таймаутами. Таким образом, вы должны хранить запросы (в основном, записи) в очередях и - после некоторого короткого таймаута - проверить правильность очереди перед пересылкой данных в процедуры вставки/обновления (/ удаления).

Answer 3

APPROACH1: Плюсы: [...] мы сначала вставляем запас в базу данных, а затем вставляем запись в другие таблицы, которые будут иметь отношения с внешним ключом.

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

Против: Этот API/ресурс имеет множество обязанностей. Он станет все больше и больше, и в будущем в этом API может быть слишком много полей.

Вы можете уменьшить негативное влияние этого поиска required fields only.