REST API - обработка сложных операций, которые не подходят для CRUD, сервера или клиента? - PullRequest
0 голосов
/ 05 июля 2018

Допустим, у меня есть объект DateRange, представленный моим API. Представление базы данных выглядит примерно так:

id: uuid,
start: date,
end: date

И мой REST API предоставляет различные функции CRUD через следующие конечные точки:

/api/v1/date-ranges/ <GET, POST>
/api/v1/date-ranges/{id}/ <DELETE, PUT, PATCH>

Эти две конечные точки отлично работают, если одна просто удаляет или редактирует весь диапазон дат (например, изменяет дату окончания или удаляет весь диапазон)

Однако мне нужно разрешить клиенту удалить дату, которая может находиться в середине диапазона (или даже весь диапазон, если start и end - это одна и та же дата). Таким образом, эта операция редактирования имеет три возможных результата:

  1. Если удаляется дата из начала или конца диапазона, существующий объект диапазона изменяется.
  2. Если дата в середине диапазона удаляется, существующий объект DateRange изменяется и создается новый объект DateRange.
  3. Если диапазон дат начинается и заканчивается в одну и ту же дату (диапазон 1 дня), и эта дата удаляется, то существующий объект DateRange удаляется.

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

Я мог бы использовать /api/v1/date-ranges/{id}/ <PATCH> и передать дату, которая будет удалена из диапазона. Тогда он может вернуть тело, которое выглядит как:

modified: {id: string, start: date, end: date}[]
deleted: {id: string}[]
created: {id: string, start: date, end: date}[]

Тогда в случаях, когда ничего не создано, он возвращает пустой массив для created, также для modified и deleted. Преимущество этого заключается в том, что API обрабатывает все операции по поддержанию правильного состояния. Однако, как я упоминал ранее, он не соответствует стандартному телу ответа REST API.

Другой вариант, который я вижу, состоит в том, чтобы клиент обрабатывал всю служебную работу и выполнял несколько вызовов API для каждой необходимой операции (например, сначала вызовите операцию PATCH, чтобы изменить существующую сущность, а затем, если необходимо, вызовите POST. операция по созданию новой сущности). Это дает преимущество сохранения RESTful, но создает возможность нарушенного состояния в базе данных, если второй вызов API прерывается / потеря сети и т. Д.

Как подобные проблемы обычно обрабатываются RESTful?

1 Ответ

0 голосов
/ 05 июля 2018

Как подобные проблемы обычно обрабатываются RESTful?

Прорабатывая, как бы вы это делали, если бы ваши ресурсы были «просто» веб-страницами.

1) Вот веб-страница; Я хочу внести в него некоторые изменения, поэтому я нажимаю на ссылку редактирования. Это подводит меня к форме, которая описывает данные, которые мне нужно включить в изменение. Я заполняю эти данные и отправляю форму. Сервер получает запрос и выясняет, как осуществить мои изменения. В ответ я получаю представление о статусе действия.

2) Вот веб-страница; Я хочу внести некоторые изменения в это. Поэтому я загружаю копию представления в предпочитаемый мной редактор и вносю необходимые изменения в свою копию. Затем я отправляю свою обновленную копию обратно на сервер. Сервер получает запрос и выясняет, как сделать его копию соответствующей моей копии. В ответ я получаю представление о статусе действия.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...