POST 的 RESTful API 中的多个路径参数与查询参数？答案

【问题标题】：multiple path params vs. query params in a RESTful API for POST?POST 的 RESTful API 中的多个路径参数与查询参数？
【发布时间】：2020-01-16 21:20:07
【问题描述】：

我正在尝试实现一个宁静的 API

我有一个名为 Program 的实体（描述和位置详细信息）

我有一个名为 Timing 的实体（程序 + 开始时间 + 结束时间）

我有一个名为 Check-In 的实体（时间 + 用户详细信息）

场景：我需要签到时间，

POST 请求的理想 URL 应该如何，选项A

POST /programme/:id/timing/:id/check-in
query param: null

选项 B

POST /check-in
request body: {programme=id,timing:id}

第一种方法将完全使用路径参数中的 id 并直接标识资源在第二种方法中，消费者告诉资源的类型，在过滤条件中提及资源的类型。

注意：我们将 UUID 用于 Program 和 Timing 资源，这会使 URL 略大

【问题讨论】：

没有 RESTful URL 这样的东西，并且有一个 request 来删除这个标签。无论如何，URL 仍然是 URL。总的来说，它是一个指向提供一些任意数据的特定资源的指针。不应从 URL 中的字符得出某些语义，因为这会导致 typed resources。除此之外，REST 与api-design 也没有太大关系。
这纯粹是一个意见问题。
@RomanVottner 正如你所说的可能没有标准，我想知道协调需求的最佳方式/各种方式。

标签： rest api-design restful-url

【解决方案1】：

两者都可以，但 GET 更适合请求信息。只要您的网址小于 4000 字节，就不会成为问题。

【讨论】：

感谢您的回复，我目前的用例是为个人计时资源注册人员。目前，我的模型已签入程序资源的一部分。抱歉，如果我的问题不清楚，请立即更新问题。谢谢

【解决方案2】：

Caching 的资源表示是 REST 架构风格中的一个重要考虑因素。

这在 HTTP 中的表达方式是，如果我们收到对不安全请求（如 POST）的非错误响应，则合规缓存应为 invalidate 资源的缓存表示。 URI 是缓存键，因此POST 请求的 target-uri 标识了要驱逐的缓存条目。

因此，在设计我们的协议时，我们会考虑哪些资源会被某个操作更改，并在进行更改时使用要更改的资源的标识符作为目标。

我们GET 使用什么资源来查看更改的效果？这应该是变更请求的目标。

POST /check-in
request body: {programme=id,timing:id}

如果GET /check-in 是您希望在客户端上查看的内容，则此拼写是有意义的。从您的描述来看，这似乎不太正确——听起来过于粗糙。

POST /programme/:id/timing/:id/check-in
query param: null

另一方面，这看起来可能过于精细；好像有人认为单一职责原则的正确应用是每个 POST 处理程序将只做一件事。

是否有一个check-out 与check-in“相配”？如果是这样，这些请求可能会发送到同一个地方

POST /programme/:id/timing/:id

action=check-in

POST /programme/:id/timing/:id

action=check-out

可能是programme，而不是timing，是您的域的正确粒度

POST /programme/:id

action=check-in&timing=:id

【讨论】：

感谢您的输入，我以不同的方式设计了资源，我的新设计看起来与“POST /register BODY {user_id: user1, timing: t1}”类似，由 Karthik 建议。

【解决方案3】：

如果您采用的是 Restful 方式，那么您希望识别适当的资源并对这些资源进行 CRUD 操作。

有 3 个资源： - 程序 - 用户 - 计划（时间是一个错误的资源名称）-> 属于-> 程序 - 注册->属于（用户，日程）

所以注册，我的宁静端点看起来像

POST /注册正文 {user_id: user1, schedule_id: s1}

【讨论】：

感谢您指出正确的方法，我已将资源重命名为 Sessions 而不是时间。我将采用这种方法“POST /register BODY {user_id: user1, schedule_id: s1}”，除了用户 ID 将成为标头本身的一部分。