我在 REST api 中命名端点时遇到问题。
假设您在客户端有一个 UI，该 UI 中有一个包含文件列表的表格。点击文件时，它将继续从服务器下载选定的文件。此外还有一个按钮，点击后将下载所有文件或选定文件。
所以 API 上的端点可能是这样的结构......
如您所见，问题在于端点与 Api/Files 的冲突。我希望两个端点都按照我指定的方式执行。但是其中一个需要改变......我考虑过在结尾添加一些东西，但我想到的大多是动词。有关如何进行格式化的任何想法？
【问题讨论】：
[GET] Api/FilesArchive 会这样做？
标签： c# api rest asp.net-core model-view-controller
查看不同的答案并对其进行测试，我认为最好的答案就是使用不同的端点名称。所以我现在去了......
这并不完美，但很有意义。
另一种可能是......
【讨论】：
HTTP/RESTy 方法是使用 Accept 标头指定所需的响应类型。如果Accept 是application/json，端点可以将结果返回为JSON，如果是application/zip，则返回一个ZIP 文件
在最坏的情况下，您可以检查请求的 Accept 标头并返回 JSON 结果或创建 ZIP 文件并使用 return File(...) 返回。
Produces 属性可用于指定每个动作返回的内容类型，允许您为每个内容类型编写不同的动作。
另一种选择是创建一个custom output formatter，并在Accept 标头请求时让ASP.NET 自己处理ZIP 文件的生成。 This blog post 展示了如何创建一个 Excel 输出格式化程序，当 Accept 标头请求时，该格式化程序将项目列表作为 Excel 文件返回
【讨论】：
我希望两个端点都执行我指定的操作。但是其中一个需要改变......
正确 - 扩展这个想法，您有三个 资源（文件内容、可用文件列表、可下载的文件存档），但只有两个 名称时间>;所以你至少需要一个名字。
好消息：REST 不关心您为资源标识符使用的拼写约定，因此您实际上并不需要一个好的名称。
/Api/0d660ac6-d067-42c1-b23b-daaaf946efc0
这样就可以了很好。机器不在乎。
人类确实在乎；如果我们不试图猜测不同 UUID 的含义，那么查看访问日志或在文档中查找内容会容易得多。
想到的大多是动词
动词很好。请注意，这些 URI 都完全按照您的预期工作：
HTTP/RESTy 方式是使用 Accept 标头指定所需的响应类型。
这里可能不是你想要的。有效的目标uri是主缓存键；当我们invalidate一个缓存条目时，所有的表示都会失效。如果这不是您想要的文件列表和可下载 zip 之间的关系，那么让它们共享资源标识符将是不愉快的。
Accept 更适用于同一事物的多个表示形式（即文件列表，但表示为 HTML、JSON、文本、XML 等）。
您还可以考虑这些标识符在访问日志中的样子；是否应该使用相同的 URI 记录文件列表和 zip？您是否希望通用日志解析工具（如警报系统）将两种不同类型的 fetch 视为等效？
【讨论】：