RESTFUL API：使用路径参数与查询参数答案

【问题标题】：RESTFUL API: Using path parameters vs Query parametersRESTFUL API：使用路径参数与查询参数
【发布时间】：2022-01-11 17:43:11
【问题描述】：

首先，我知道当您指向资源时需要使用路径参数，而当您定义可以添加“属性”（或及时更改）的内容时，需要使用查询参数。

但是，假设我需要获取属于某个用户的数据。

在这种情况下，我喜欢这样编写 REST API URL。

https://mylink/user/getbyid

不是

https://mylink/user/get

在我编写 REST API 的方式中，我将调用 URL，例如 /user/getbyid?id=1。在我不编写 API 的方式中，您将其称为 /user/get/1。

由于我编写了诸如/user/getbyid、/user/getbyname、/user/getbyuid 之类的 API 调用，因此我很少使用路径参数。 99% 的时间我都在使用查询参数。

考虑到我编写 api 调用的方式，我是否违背了最佳实践？还是我做的是对的还是可忽略的？

【问题讨论】：

getbyid 更像 rpc 而不是 REST。 REST 将是 GET /user/{id}。对于搜索，我看到 POST /user 带有一个包含过滤器的 JSON 正文，例如{“名称”：“名称”}

【解决方案1】：

我知道当您指向资源时需要使用路径参数，而当您定义可以添加“属性”（或及时更改）的内容时应该使用查询参数。

这实际上是不对的 - 欢迎您根据自己的喜好将信息编码到路径或查询中；只要您的标识符与 RFC 3986 中定义的生产规则一致，机器就不会在意。

“资源标识符”包括路径和查询部分。

自从我编写 API 调用（如 /user/getbyid、/user/getbyname、/user/getbyuid）以来，我很少使用路径参数。 99% 的时间我都在使用查询参数。

是的，那很好。

考虑到我编写 api 调用的方式，我是否违背了最佳实践？还是我做的是对的还是可忽略的？

我会说，可以忽略不计。资源标识符很像变量名。人们可以花几个小时争论变量名，而机器不在乎。资源标识符也是如此。

这些标识符可以改进吗？我想是这样;关键思想是我们正在识别resource，而不是识别资源如何实现的实现细节。标识符在某种意义上是“文档的名称”。

删除 getby... 路径段也可以。

/users?id=1
/users?name=bob
/users?uuid=469149ae-ecc6-4652-b094-17c211ff58ef

...但是，根据您的路由实现，消除这三个资源的歧义可能很笨拙。添加额外的路径段以使路由更容易很好。

【讨论】：

【解决方案2】：

设计 REST API 以执行基本 CRUD（创建、读取、更新、删除）操作的最佳实践是结合使用 HTTP 方法 GET POST PUT PATCH DELETE、URL 和/或参数。

假设您要设计一个 REST API 来为用户执行 CRUD 操作

1.创建

要执行创建，请使用POST http 方法设计端点/users。

# http method  URL parameters
POST https://<yourdomain>/users, { first_name: "Peak", last_name: "Gen"}

2。阅读

要执行Read，请使用GET http 方法设计一个端点/users/<id>。

# http method  URL parameters
GET https://<yourdomain>/users/1

2。更新

要执行Update，请使用PUT 或PATCH http 方法设计一个端点/users/<id>。

# http method  URL parameters
PUT https://<yourdomain>/users/1, { first_name: "Nitin", last_name: "Sri"}

2。删除

要执行Delete，请使用DELETE http 方法设计一个端点/users/<id>。

# http method  URL parameters
DELETE https://<yourdomain>/users/1

如果您注意到，在读取、更新和删除中使用了相同的 URL，而它们的 HTTP 方法不同。表示相同的 URL 路由到基于其 HTTP 方法的不同操作。

阅读更多关于REST API

【讨论】：