Допустим, у меня есть объект 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
- это одна и та же дата). Таким образом, эта операция редактирования имеет три возможных результата:
- Если удаляется дата из начала или конца диапазона, существующий объект диапазона изменяется.
- Если дата в середине диапазона удаляется, существующий объект
DateRange
изменяется и создается новый объект DateRange
.
- Если диапазон дат начинается и заканчивается в одну и ту же дату (диапазон 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?