«Restful» решение принять список объектов - PullRequest
Новая
       6

«Restful» решение принять список объектов

0 голосов
/ 15 февраля 2020

Я смотрю на сценарий, в котором у нас есть один родитель resource (настоящее имя удалено, чтобы защитить невинных). Как дочерний объект, у нас есть список prices, упорядоченный поffectiveDate. 

Preexisting CRUD on api/resource
New POST on api/resource/{code}/someRelationship/{relId}/prices

Через несколько месяцев go мы создали конечную точку POST prices. Требуется список price объектов. В настоящее время это добавляет новый prices к уже существующему списку в базе данных. Там нет обработки дубликатов, когда мы потребляем эти prices, кроме последнего в выигрыше, если действующие даты совпадают. Мы не открывали идентификатор и просто хотели связать некоторый prices с родительским resource объектом, заданным someRelationship. 

{
  "prices": [
    {
      "price": 0,
      "effectiveDateTime": "2020-02-14T18:30:33.710Z"
    }
  ]
}

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

Опции:

  1. Опираться на POST api/resource/{code}/someRelationship/{relId}/prices
    • Можем ли мы продолжать обрабатывать объект prices как список, принадлежащий родительскому resource, а не как объект первого класса, restful?
    • Измените POST logi c, чтобы стереть старые prices и сохранить новые, которые были переданы вызывающей системой, так как она знает обо всех prices и может сохранить их в одном вызове. ,
    • Мы можем поспорить, должно ли оно называться PUT или POST. Для меня это звучит как POST.
    • Мне сказали, что это нарушает все, что свято, с условными обозначениями отдыха.
    • Пришлось бы обновить api docs для передачи этой функциональности, потому что мы нарушили условные обозначения отдыха.
  2. продвигает объект prices в первоклассный, спокойный объект API.
    • Но это означает, что нам придется создавать полные конечные точки CRUD, выставляющие идентификатор
      • или использовать эффективноеDateTime в качестве идентификатора, который кажется странным
    • Рабочий процесс для вызывающего абонента жонглировать полным CRUD prices
      • GET /api/resource/{code}/someRelationship/{relId}/prices
        • , чтобы получить список, чтобы узнать, какие изменения в pu sh более
      • price в обе стороны с одинаковым значением и действующей датой? Ничего не делать.
      • POST /api/resource/{code}/someRelationship/{relId}/prices
        • price отсутствует на стороне для синхронизации? ПОСТ это один за другим? Или мы можем добавить его в список и POST список? Что делать, если у нас есть 100 цен? 100 вызовов API?
      • PUT /api/resource/{code}/someRelationship/{relId}/prices/{id}
        • price неправильно со стороны для синхронизации? Поместите его один за другим.
      • DELETE /api/resource/{code}/someRelationship/{relId}/prices/{id}
        • price в сторону, которая будет синхронизирована, но отсутствует в источнике истины? Удалите его по одному.
    • сравнительные логи c могут стать более запутанными, если мы продолжим добавлять поля к значению price (больше, чем цена andffectiveDate)
    • Пример: умножить на 12 месяцев несколько родителей resources. 12 месяцев * 100 price API-вызовы * 5 resources = 6000 вызовов?
...