我具有以下REST API端点：
GET /api/games
返回一个带有游戏列表的JSON。
就REST / API设计规则而言，对于同一个端点，在实施方面是否存在任何规则，或者是强制性的（或可选的），也可以这种形式访问：
GET /api/games/
我看过“生产级” API支持两种形式的“相同端点”的API路径，以及其他仅支持第一种书面形式的API，所以我不确定这是否不好练习与否。
答案 0 :(得分：3)
没有硬性规定，而是最佳做法。
例如，我倾向于从Stripe's API看灵感，因为它已经相当成熟并且被广泛使用。它们不倾向于支持斜杠。
示例
使用他们的API，这将起作用：GET https://api.stripe.com/v1/customers
另一方面，这不会：GET https://api.stripe.com/v1/customers/。它返回一条invalid_request_error消息。
此外，此source建议您不要添加斜杠，因为这可能会使您的消费者感到困惑。
我个人避免使用它们。
答案 1 :(得分：2)
我不认为有确切的答案-尽管this answer有一些信息。
作为一个纯粹主义者，我想说带斜杠的URL表示有可用的子级，而没有带斜杠的URL表示特定的资源。人类可能将“游戏”识别为复数形式，但是计算机代码可能不会。此外，有些单词具有相同的单数和复数形式，因此依靠文件夹名称的复数形式会感到很脆弱。
我的实用主义者说，人会犯错，我的API应该尽可能地易于使用。因此，我的文档需要定义行为是什么，并且我的错误消息应该清晰明了。
答案 2 :(得分：1)
GET /api/games
GET /api/games/
REST中没有规则要求仅由于资源标识符不同而存在不同的基础实现。
没有规则可以禁止两个资源临时或永久地共享通用表示。
同样，REST中没有规则可以区分资源标识符的拼写的“小”和“大”差异。您在这里拥有两个不同的标识符，因此有两个不同的资源。从REST客户端的角度来看，这两个标识符与（或小于）类似：
GET /11B3FE64-087A-41E8-A067-235C6FA427B1
GET /141289D7-8D4D-4BC2-8A5E-D8EE33BD3818
例如，这意味着高速缓存将对两种资源的处理方式有所不同-REST并没有给您提供协调cache invalidation的期望。
关于人类可读标识符的约定是由相关人类的期望驱动的。机器不在乎。