rest - 如果我不使用它们，是否需要将路径参数放在 URI 中[REST API]
问题描述
我正在与我的一位前辈在工作中进行辩论，我想知道他所说的是否属实。想象一下，我有一个/users/bucket-list获取当前登录用户存储桶列表的路径。现在我的问题是，既然我从上下文中获取了登录用户的 ID，我还需要像这样命名我的路径吗/users/:user_id/bucket-list？我不使用路径参数，但我的前辈认为它应该仍然存在，我认为因为我不使用它，所以我需要省略它。我想听听你对此的看法。
解决方案
TL; 博士
- 你这样做是不对的”
- 大多数时候，你会侥幸逃脱
- 逃避它是错误的目标
- 大多数时候，你会侥幸逃脱
任何可以命名的信息都可以是一种资源——菲尔丁，2000
在大多数情况下，我发现推理“资源”的最简单方法是替换“文档”，然后一旦基本想法到位，然后在必要时进行概括。
我们在创建 API 时面临的设计问题之一是弄清楚我们的资源；“爱丽丝的遗愿清单”应该与“鲍勃的遗愿清单”分开呈现，还是它们属于一起？我们是为整个列表提供一个资源，还是为列表中的每个条目提供一个资源，等等。
我们在设计中需要考虑的一个相关问题是资源应该支持多少表示。这可能包括选择支持多种文件格式（csv vs 纯文本 vs json 等）和不同的语言（EN vs FR）等等。
你的上级提出的设计类似于拥有两种不同的资源。这样做之后，一切都会正常工作[tm]。识别哪个资源没有混淆，授权与识别完全分开，等等。
然而，您的设计类似于具有多个表示的单个资源，其中一个表示是根据查看它的人来选择的。这有点乱——当然您的服务器可以解释 HTTP 请求，但通用组件不会知道您的资源与 Internet 上的所有其他资源具有不同的标识语义。
我们通常使用 Vary 标头来区分不同的表示；但是 Authorization 字段有点超出范围，请参阅RFC 7231。
在实践中，您可能会逃脱您的设计，因为我们有关于共享缓存如何与经过身份验证的请求交互的特殊规则，请参阅RFC 7234。
但是“可能逃脱它”是相当弱的。拥有共同标准的目的是获得互操作性。如果你打算冒险互操作，你最好得到一些非常有价值的东西作为交换。您在此处提出的任何内容都没有显示出补偿性优势。