设计restapi

在我的应用程序中，我会让客户尝试预订一些插槽。为此，客户机将提供一些输入，根据这些输入，我必须首先创建这些插槽，然后将它们返回给客户机。在获得插槽后，用户将预订其中一个插槽。此“book”操作不是创建任何新资源，而是简单地修改2个现有资源

我应该如何设计我的URI以及使用什么方法

编辑：

我有1个现有资源，其URI为：/api/v1/vehicle/id

使用应用程序前端，用户将填写一些表单数据，包括

日期

和

预订类型

字段并提交。然后，后端将使用此数据“计算”（当前不存在名为

slots

的资源）用户可用的预订时段。然后，这些计算的

插槽将保存在数据库中，并作为响应返回给用户。在这些插槽中，用户将
预订
插槽。但是，此
book
操作不会创建任何新的资源，而是简单地修改现有的
vehicle
资源（向其中添加预订相关数据）和先前请求返回的slots对象。我想为此创建一个RESTAPI

我想这样做：

POST /api/v1/slot                    (1)
PUT/PATCH /api/v1/vehicle/id            (2)
PUT/PATCH /api/v1/slot/id            (3)

首先，我不确定是否应该在（2）和（3）中使用
PUT
或
PATCH
。我将只提供部分更新的请求。其次，当用户选择一个插槽并单击
book
按钮时，前端只能向服务器发送一个请求。但是在这里，我需要修改2个参考资料。我该怎么做？我想我应该创建一个URI，比如/api/v1/createbooking，并使用POST方法。然后在我的后端调用两种不同的方法来更新
vehicle
和
slot
对象。这个URI结构和命名好吗

我应该如何设计我的URI以及使用什么方法

你会如何处理网页

这听起来像是让用户导航到一个表单，该表单收集日期、预订类型等。用户提交表单，并将信息发送到服务器；因为这本质上不是只读操作，所以我们希望表单指示应该使用POST方法

服务器将进行本地更改，并向用户显示一个新表单，其中输入控件显示可用选项。再一次，选择插槽似乎没有只读语义（我们正在将信息传递给服务器），因此我们将再次看到帖子

URI目标是什么？选择哪些资源应该处理POST请求的一种方法是考虑其含义；因为缓存知道使成功POST请求的目标uri无效，所以将请求成功时可能更改的资源作为目标可能很有用

我的猜测是，第一篇文章将转到显示插槽选择的资源（因为我们正在为客户生成新的选择）

对于第二次提交，由于车辆的表示将通过选择一个槽来更改，因此将POST请求发送到车辆uri是有意义的

一般来说，考虑如何从服务器读取（获取）不断变化的信息；您可以通过向同一URI发送一些请求来更改该信息


我不确定我是否应该在这里使用PUT或PATCH

PUT和PATCH通常一起提供，而不是作为不同的东西。它们是发送资源的替换表示的两种不同方法

一个简单的例子：如果您想更改
/home.html
的标题，您可以将整个html文档添加到新标题中，也可以通过以服务器理解的某种格式发送修补程序文档来修补html文档

换句话说，这两种方法都具有远程创作语义；我们通常会根据与您的域模型无关的考虑因素在它们之间进行选择（如果文档相对于HTTP头的大小很小，客户端通常会选择PUT作为附加的幂等语义保证。如果文档确实很大，但更改很小，我们可能更喜欢补丁）


我需要修改2个资源

没有规定一个请求只能修改一个资源。更改的副作用可能会影响多个资源的表示（请参阅RFC 7231的和）

棘手的是告诉通用客户机（和中间组件）哪些缓存表示会因更改而无效。开箱即用，我们只有有效请求uri、位置和内容位置的语义。位置和内容位置已经有了意义，所以你不能在不引起混乱的情况下劫持它们）

您可以使用，使用“已知”链接关系来标识已被请求更改的其他文档。不幸的是，LCI似乎没有达到“标准”的状态，因此我们目前可能运气不佳。
您必须提供更多详细信息。“目前很难有人提出任何建议：）@SriHans补充了细节感谢这个惊人的答案，它非常有用。不过我还有几个问题。“LCI似乎没有达到“标准”的状态，因此我们可能暂时运气不佳”因此在我的情况下，如果我不处理这个问题，客户端可以从缓存返回旧响应，而不是发出新的请求？