我是否应该在restful api中添加连接词？

假设我有一个控制器，它有三个参数：

class Dog {
    function tell (dogId, commandId, rewardId) {
         // blah
    }
}

我访问的url可能是：

 mysite.com/dog/tell/1/2/3

在这种情况下，您必须记住，参数按该顺序映射到

dogId

，

commandId

&

rewardd

。另一种方式可能是：

mysite.com/dog/tell/1/command/2/reward/3

或者，为了更清楚（但可能会让您的框架更复杂）：

哪个更好？哪个更常见？乍一看似乎越清晰越好。但是，您仍然必须记住参数的顺序，现在还必须记住关键字。（“是‘狗／命令／奖励’还是‘命令／狗／奖励’或‘狗／给／给’还是……？）

---

想法？参考文献：）

对于一个网站来说，我想说有连接词是有用的，对于一个api来说，我想说的不是，好的文档是api所需要的全部。

mysite.com/tell/dog/1/command/2/reward/3

看起来很像

mysite.com/tell？dog=1&command=2&reward=3

在第二种情况下，顺序绝对不重要。最有可能的是，在第一种情况下，这也不重要。如果我是你，我会接受任何组合，因为它显然不像URL预期的那样具有层次性。此外，你不能指望

mysite.com/tell/dog/1

做一些有用的事情

由于狗id、命令id和奖励id仅在一起才有意义，因此我要陈述这一事实，并设定顺序：

mysite.com/tell/dog-a-command-by/1/2/3

甚至

mysite.com/tell/dog-a-command-by/1-2-3

---

因为你不能指望mysite.com/tell/dog-a-command-returning-by/1也做一些有用的事情。

就我个人而言，我更喜欢像mysite.com/dog/1/tell这样的url，并通过POST传递command=2和return=3。也许数据中也有狗的ID。 有几个原因：

具有后果的操作不应该通过GET完成，但是将整个请求放在URL中会使GET非常诱人

REST只是说请求应该包含执行操作所需的所有内容，而不是URL应该包含的内容。考虑到#1，我甚至会说把所有内容都塞进一个可获取的URL是个坏主意

使它更加通用；在URL上发布一个HTML表单就足以测试它了

正如其他人提到的，URL旨在形成一个层次化名称空间。当你把你的参数放在URL中时，你打破了这一点，因为（1）在“命令”和“奖励”之间没有明确的父/子关系，（2）如果没有一个参数是可选的，它会导致很多无效的URL。命名参数会让事情变得更糟，因为现在同一个“资源”有6个不同且功能相同的URL…如果您的框架真的支持这样做的话

---

您似乎没有在这里创建RESTful API。RESTAPI使用URI来表示资源，而不是操作（

tell

在我看来就像一个操作）。对资源的操作由所有资源通用的接口定义。我假设您正在使用HTTP设计RESTAPI，因此您的公共接口由HTTP动词GET、POST、PUT、DELETE等定义

所以，与其用操作

tell

来定义我们的服务，不如让我们先考虑一个资源：狗。作为一名客户，让我们假设我正在寻找罗孚的狗。我与您的服务的第一次交互可能是这样的请求：

GET mysite.com/dogs?q=Rover

在对这个请求的响应中，我们假设我得到了一个表示狗的资源的URL:

mysite.com/dogs/3759

现在，让我们了解狗的状态：

GET mysite.com/dogs/3739

在响应中，我看到小狗罗孚还活着，醒着，站着（即，响应告诉我小狗罗孚的状态）。响应还包括我可以用来导致该资源状态转换的表单（即，响应告诉我如何使漫游者更改状态）

现在，下一步是告诉罗孚做点什么。我们希望漫游者的状态从站立状态过渡到坐下状态（假设我们不能简单地将漫游者的状态从站立状态更新为坐下状态，我们只能发出漫游者可以选择跟随的命令-就像一只真正的狗一样！）。让我们将

sit

命令发布到Rover：

POST mysite.com/dogs/3739
<command name="sit"/>

状态告诉我，该数据已被Rover接收，并已导致创建新资源（我们的命令）。如果我们想获得这个命令的状态，我们可以通过向Location头中给定的URL发出请求来查看它。让我们这样做，并了解新创建的命令：

GET mysite.com/dogs/3739/commands/1299

现在，响应将告诉我该命令的状态。让我们假设我们运气好：该命令已被执行（为此资源返回的表示包含一些信息，如

followerd=true

）。响应还包括一个指向代表漫游者（向其发出命令的狗）的资源的链接

最后，当我们请求代表漫游者的资源的状态时：

GET mysite.com/dogs/3739

我们从回复中看到，状态转换已经发生，现在我们被告知，罗孚正在“坐着”。响应还可能包括对迄今为止罗孚以链接到此URI的形式发出的命令列表的引用：

mysite.com/dogs/3739/commands/

这更接近于RESTful模型。我认为，你在这里选择的领域可能会使事情更难解释和理解。“command”资源让人费解，而且听起来非常复杂，但是“command”这个词实际上只是用来指宠物。实际上，“命令”只是你给狗发送的一条信息。当我们将单词“command”替换为单词“message”时，更容易看出消息是一种肯定具有状态的资源

简言之（tl；dr）：

• 为资源而不是操作提供URI
• 创建/更新资源（导致状态转换）

  GET mysite.com/dogs/3739
  

  mysite.com/dogs/3739/commands/