Мы создаем REST API для одного из наших приложений, и мы столкнулись с проблемой и ищем некоторые рекомендации, которые помогут нам принять решение, которое позволит нам привести наши API в соответствие с отраслевыми стандартами.Пожалуйста, поделитесь любой статьей, которую вы знаете, которая поможет нам в принятии решений.
Вот наша проблема.
В нашем приложении есть определенные ресурсы, которые содержат поля, связанные с некоторой логикой.Изменение такого поля вызывает обновление некоторых других.Допустим, у нас есть счет-фактура, и этот счет-фактура содержит несколько элементов счета-фактуры, обновление количества данного элемента счета-фактуры приведет к обновлению цены элемента счета-фактуры и общей цены счета-фактуры.Цены хранятся в целях отчетности, поэтому мы не хотим вычислять их по требованию.
Пока мы изучаем эти два варианта: 1. Мы используем запрос на исправление, чтобы обновить количество позиций в счете и применитьлогика, поскольку мы применяем новое количество к ресурсу (на стороне сервера, поэтому мы применяем нашу логику).Мы реализовали необязательный параметр, который вызывающий мог бы использовать для получения всего ресурса, который был изменен запросом исправления, на тот случай, если он захочет получить результирующий ресурс.
url:
patch api/data/invoice-item/id?returnUpdatedResource=true
data:
{
"quantity": 20
}
result:
{
"invoiceItemId": 123,
"item": "SomeItem",
"quantity": 20,
"price": 123.00,
...
}
Другими вариантами могут быть конкретные действия, связанные с этими полями, что предполагает обновление других полей.Действие потребует, чтобы данная модель была отправлена с запросом в случае, если для применения логики потребуется более одного поля.
url:
post api/data/invoice-item/id/updateqty?returnUpdatedResource=true
data:
{
"quantity": 20
}
result:
{
"invoiceItemId": 123,
"item": "SomeItem",
"quantity": 20,
"price": 123.00,
...
}
Вариант № 1 имеет простоту универсальности, поэтому нашAPI остается довольно простым, но потребует документирования этих возможных побочных эффектов.Преимущество варианта № 2 состоит в том, что он более многословен, но привнесет много новых возможных URL для нашего API.
Какие-либо рекомендации или рекомендации, которые вам известны, которые помогут нам принять решение?