Rest API 命名约定，更好的建议？答案

【问题标题】：Rest API naming convention, better suggestions?Rest API 命名约定，更好的建议？
【发布时间】：2019-12-05 11:29:19
【问题描述】：

我有类似以下的端点，但找不到适合我情况的最佳做法。您对以下四个休息端点有更好的建议吗？

1. facebook/impression/count?date_from=01-05-2019&date_to=27-07-2019

// returns
{
  "account": "foo",
  "channel": "facebook",
  "value": 4730519
}

2。 facebook/fan/count?date_from=01-05-2019&date_to=27-07-2019

// returns
{
  "account": "foo",
  "channel": "facebook",
  "value": 4730519
}

3. facebook/fan/change-rate?date_from=01-05-2019&date_to=27-07-2019

// returns
{
  "account": "foo",
  "channel": "facebook",
  "value": 25
}

4. facebook/video-view/count?date_from=01-05-2019&date_to=27-07-2019

// returns
{
  "account": "foo",
  "channel": "facebook",
  "value": 2512333
}

第二种方法可能是这样的：

【问题讨论】：

【解决方案1】：

Rest API 命名约定，更好的建议？

REST 不关心您对资源标识符使用什么拼写，只要它们与 RFC 3986 中规定的生产规则一致。

所以你所有的例子都很好。

/facebook/impression/count?date_from=01-05-2019&date_to=27-07-2019
/facebook/impression?metric=count&date_from=01-05-2019&date_to=27-07-2019

在这种情况下，权衡是为了方便。我们有relative resolution 允许我们引用同一层次结构中的其他标识符，但这是基于路径段。

/facebook/fan/count + ../change-rate === /facebook/fan/change-rate

查询部分没有类似的解决方案 - 您必须替换整个内容。

另一方面，HTML 已经有了将客户端提供的参数转换为application/x-www-form-urlencoded 查询字符串的标准；如果您支持 HTML 客户端，并且希望将 `[change-rate,count,view-count] 视为客户端提供的参数，这会很方便。

HTTP 已内置在其中 redirection semantics;如果你在做 REST，那么你可以改变你对标识符的想法，让旧的支持新的。拥有两个提供相同表示的资源并没有错，所以这是另一种选择。

路径组件包含通常以分层形式组织的数据，以及非分层查询组件中的数据

许多人更喜欢（尽管并非绝对必要）是在资源标识符的拼写中反映资源的层次结构。因此，如果count 资源从属于fan 资源，则/facebook/fan 和/facebook/fan/count 反映了相同的层次结构。

但这不是必需的——网址缩短器工作。

总之，机器不关心标识符中的域语义，所以除了一些小的机械问题之外，所有合理的人类可读拼写都是等价的。

【讨论】：