REST命名最佳实践/观点-只使用变量而不使用任何名词可以吗？

不确定我在这里使用的术语是否正确，但最好在示例中解释：
如果我使用API来检索给定区域中的人口计数，通常可以吗

/population/{state}/{city}/{district}

或者我应该使用

/population/states/{state}/citys/{city}/districts/{district}

案例AAPI只返回一个数字，具体取决于您指定的数量
案例BAPI只返回一个数字，但您必须始终指定每个变量，这意味着仅定义州和城市是无效的：

---

我想最好选择解释性更强的。或者我是否缺少其他逻辑？

一般来说，对于REST端点，“/”表示您正在访问子资源。所以这真的取决于你想做什么

据我所知，您的主要目标是检索给定多个参数的总体

因此，

/population/state/{state}/city/{city}/district/{district}

公约将起作用，如果您考虑到以下几点：

• /population

  ：返回总人口

• /population/states/

  ：返回每个州的总人口

• /population/states/{state_name}

  ：返回 给定的州及其各个组成城市
• 等等

注意，我对子资源名称使用了复数形式，即

状态

，而不是

状态

但是，如果您只想返回一个数字，而不是一个细分数字，那么您可以考虑：

---

获取

/population？state=stateName&city=cityName&district=districtName

我已经更新了这个问题，以便根据您的答案进一步指定，使其更清晰。如果您总是计划返回单个数字，而从不返回子资源细分（即所有城市的人口细分等），我相信使用参数而不是子资源更为相关（即我提供的GET示例）。首先，因为它会在需要时将子资源的使用保留到另一个时间。其次，例如，如果您希望在将来添加另一个级别的过滤器（在州和地区之间的某个位置），您不会希望更改顺序并影响您的消费者（即，而不是“人口/{states}/{city}，它变成了“人口/{states}/{newFilter}/{district}..。我不认为这是一种正确或错误的方法，只是尝试保留子资源的使用（如果不是真的需要）。如果你只热衷于坚持你提供的其中一个选项，那么在我看来，你的选项1更好。没有“REST命名约定”。REST没有命名约定。两者都很好，第一个看起来更优雅一些。请记住，当你作为一个用户在邮递员中像疯子一样在标签之间切换，看到一堆URL时，就像/324/23/11一样，你很容易迷失方向。