REST API可以至少以两种方式拥有参数:

作为url路径的一部分(即/api/resource/parametervalue) 作为查询参数(例如/api/resource?=参数值)

这里的最佳实践是什么?什么时候使用1,什么时候使用2,有什么一般的指导方针吗?

真实世界的例子:Twitter使用查询参数来指定间隔。(http://api.twitter.com/1/statuses/home_timeline.json?since_id=12345&max_id=54321)

把这些参数放在URL路径中会被认为是更好的设计吗?


当前回答

在我看来,参数应该更好地作为查询参数。url用于标识资源,而添加的查询参数用于指定您想要的资源的哪一部分、资源应该具有的任何状态等等。

其他回答

根据REST实现,

1)路径变量用于对资源的直接操作,如联系人或歌曲 前女友. . 获取etc /api/resource/{songid}或 GET etc /api/resource/{contactid}将返回相应的数据。

2)查询perms/参数用于间接资源,如一首歌的元数据 . ., GET / api /资源/ {songid} ?Metadata =genre它将返回特定歌曲的类型数据。

这个主题的一个“维度”被忽略了,但它非常重要:有时“最佳实践”必须与我们正在实现或增强REST功能的平台相一致。

实际的例子:

现在许多web应用程序都实现了MVC(模型、视图、控制器)架构。他们假设提供了一个特定的标准路径,当那些web应用程序带有“启用SEO url”选项时更是如此。

这里只提一个相当有名的网络应用程序:OpenCart电子商务商店。 当管理员启用“SEO url”,它期望说url来一个相当标准的MVC格式,如:

http://www.domain.tld/special-offers/list-all?limit=25

在哪里

special-offers是处理URL的MVC控制器(显示special-offers页面) List-all是控制器要调用的动作或函数名。(*) Limit =25是一个选项,表示每页将显示25个项目。

(*) list-all是我使用的一个虚构的函数名。实际上,OpenCart和大多数MVC框架都有一个默认的、隐含的(通常在URL中省略)索引函数,当用户想要执行默认操作时,就会调用该索引函数。真实世界的URL是:

http://www.domain.tld/special-offers?limit=25

现在有了一个类似于上面的相当标准的应用程序或框架结构,你经常会得到一个针对它进行优化的web服务器,为它重写URL(真正的“非SEOed URL”应该是:http://www.domain.tld/index.php?route=special-offers/list-all&limit=25)。

因此,作为开发人员,你要面对的是处理现有的基础设施,并适应你的“最佳实践”,除非你是系统管理员,确切地知道如何调整Apache / NGinx重写配置(后者可能很讨厌!)等等。

因此,你的REST API通常会更好地遵循参考web应用程序的标准,无论是一致性还是易用性/速度(从而节省预算)。

回到上面的实际例子,一个一致的REST API应该是类似这样的url:

http://www.domain.tld/api/special-offers-list?from=15&limit=25

或者(非SEO URLs)

http://www.domain.tld/index.php?route=api/special-offers-list?from=15&limit=25

使用“路径形成”参数和“查询形成”参数的混合。

以下是我的观点。

查询参数被用作请求的元数据。它们充当现有资源调用的过滤器或修饰符。

例子:

/ / 2014-08-08 /日历事件

应该给出当天的日历事件。

如果需要特定类别的事件

/日历/ 2014-08-08 /事件吗?类别=约会

或者你需要超过30分钟的比赛

/日历/ 2014-08-08 /事件吗?时间= 30

试金石测试是检查在没有查询参数的情况下是否仍然可以提供请求。

作为一名经常在客户端工作的程序员,我更喜欢使用查询参数。另外,对我来说,它将URL路径从参数中分离出来,增加了清晰度,并提供了更多的可扩展性。它还允许我在URL/URI构建和参数构建器之间有单独的逻辑。

我很喜欢曼努埃尔·阿尔达纳说的另一种选择如果有某种树的话。我可以看到用户特定的部分被树形分开。

如果有记录在案的最佳实践,我还没有找到它们。然而,当我决定在url中放置参数时,这里有一些指导原则:

可选参数往往更容易放在查询字符串中。

如果您希望在参数值与现有资源不对应时返回404错误,那么我倾向于使用路径段参数。例如:/customer/232,其中232不是有效的客户id。

然而,如果你想返回一个空列表,那么当参数没有找到时,我建议使用查询字符串参数。例如/联系人吗?name =戴夫

如果一个参数影响URI空间的整个子树,则使用路径段。例如,语言参数/en/document/foo.txt和/document/foo.txt?语言= en

我希望唯一标识符位于路径段中,而不是查询参数中。

uri的官方规则可以在这个RFC规范中找到。这里还有另一个非常有用的RFC规范,它定义了参数化uri的规则。