Question

我见过这样的一些问题，但是几年前他们就是这样，我想知道这些日子是否有更好的标准。

假设我的API看起来像这样：

/api/people
 ?age=21
 &name=\w*
 &country=Something
 &state=Someplace
 &city=Somewhere
 &language=English
 &includeRelatives=True|False
 &includePersonalDetails=True|False
 &includePersonalPreferences=True|False
 &includeTravelDetails=True|False
 &includeOtherStuff=True|False

等等。这对我来说不太好看。

其他人推荐这种方法（对于“include *”参数）

&includes=relatives,personaldetails,personalpreferences,traveldetails,otherstuff

因此，客户可以选择加入他们想要包含在一个参数中的内容。

所有这些都说，假设查询参数列表实际上比这长，那么适当的RESTful API有什么好的模式/实践？

Answer 1

一种常见的方法是POST到您的人员集合，将您的数据放在http正文中定义的Json或xml结构中。然后，您的api将返回201以及人员记录的唯一身份。

然后，特定的更新将被发布（或者可能是补丁）到该资源。 PUT可用于完全替换记录。

EG。 POST /人员创建新资源 POST / PATCH / people / 123进行更新 PUT / people / 123用新内容替换所有数据。

我认为没有一个gloglobally接受的休息标准，但有一些普遍接受的共同方法和很多意见！： - ）

千电子伏。

Answer 2

使用defined vs undefined代替True vs False，您可以拥有更短的URI。

例如：

http://acme.org/people?includePersonalDetails&includeOtherStuff

而不是

http://acme.org/people?includeRelatives=False&includePersonalDetails=True&includePersonalPreferences=False&includeTravelDetails=False&includeOtherStuff=True

只有当你将所有布尔选项设置为true时，URI才会（几乎）与你一样长。

使用大量查询参数设计RESTful API

2 个答案: