REST API-处理不适合CRUD，服务器或客户端的复杂操作？

Question

让我们说我的API公开了一个DateRange实体。数据库表示形式类似于：

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创建新实体的操作）。这样做的好处是可以使事物保持REST状态，但是如果第二次调用API中断/网络丢失等，则可能导致数据库中的状态损坏。

通常如何以RESTful方式处理此类问题？

Answer 1

  

通常如何以RESTful方式处理此类问题？

如果您的资源只是“纯净”网页，请按照以下步骤进行操作。

1）这是一个网页；我想对其进行一些更改，因此我单击编辑链接。这使我进入一个表单，该表单描述了更改中需要包含的数据。我填写这些详细信息，然后提交表格。服务器收到请求，并弄清楚如何进行更改。在响应中，我得到了动作状态的表示。

2）这是一个网页；我想对其进行一些更改。因此，我将表示的副本加载到首选编辑器中，然后对副本进行更改。然后，我将更新后的副本发送回服务器。服务器收到请求，并弄清楚如何使其副本与我的副本一致。在响应中，我得到了动作状态的表示。