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

Question

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

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

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

https://mylink/user/getbyid

并且不

https://mylink/user/get

在我编写REST API的方式中，我会调用像

/user/getbyid?id=1

这样的URL。顺便说一下，我不写API，你会称它为

/user/get/1

。

自从我编写像

/user/getbyid

、

/user/getbyname

、

/user/getbyuid

这样的 API 调用以来，我很少使用路径参数。 99% 的时间我都在使用 查询参数。

考虑到我编写 api 调用的方式，我是否违反了最佳实践？或者说我的做法是正确的还是可以忽略的？

Answer 1

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

这实际上是不对的 - 欢迎您根据需要将信息编码到路径或查询中；机器不在乎，只要你的标识符符合 RFC 3986 中定义的生产规则即可。

“资源标识符”包括路径和query_part。

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

是的，那很好。

考虑到我编写 api 调用的方式，我是否违反了最佳实践？或者说我的做法是正确的还是可以忽略的？

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

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

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

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

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

很好

。

设计 REST API 来执行基本 CRUD（创建、读取、更新、删除）操作的最佳实践，使用 HTTP 方法

Answer 2

、URL 和/或参数的组合。

假设你想设计一个REST API来为User执行CRUD操作

1。创建

要执行创建，请使用 /users

http 方法设计端点

POST

。

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

2。阅读

要执行 Read

，请使用

/users/<id>

 http 方法设计端点 

GET

。

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

2。更新

要执行 Update

，请使用

/users/<id>

 或 

PUT

 http 方法设计端点 

PATCH

。

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

2。删除

要执行 Delete

，请使用

/users/<id>

 http 方法设计端点 

DELETE

。

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

如果您注意到，读取、更新和删除中使用相同的 URL，但它们的 HTTP 方法不同。意味着相同的 URL 根据 HTTP 方法路由到不同的操作。了解更多关于

REST API