REST中将某些内容导出为PDF或其他文档类型的最合适方法是什么？
下一个例子解释了我的问题：
我有一个名为香蕉的资源。我为该资源创建了所有规范的CRUD rest端点(即GET/banans；GET/banans/{id}；POST/banans/{id}…(现在我需要创建一个端点来下载一个文件(PDF，CSV，..(，其中包含所有香蕉的表示。
我首先想到的是GET /bananas/export，但在纯rest中，不应该允许在url中使用动词。使用更合适的httpMethod可能很酷，比如EXPORT /bananas，但不幸的是，这还不可能。
最后，我考虑在同一个GET /bananas端点上使用Accept头，它基于不同的媒体类型(application/json，application/pdf，..(返回相应的数据表示(json，pdf，..(，但我不确定我是否以这种方式滥用了Accept头。
有什么想法吗？
REST不在乎您在资源标识符中使用什么拼写约定。
示例：https://www.merriam-webster.com/dictionary/post
即使"；张贴"；是一个动词(更糟糕的是，一个HTTP方法令牌！(，URI的工作方式与网络上的其他资源标识符一样。
从REST的角度来看，更有趣的问题是标识符应该与其他上下文中使用的标识符相同还是不同。
REST非常关心缓存(这对于实现web"web规模"非常重要(。在HTTP中，缓存主要是重新使用先前的响应。基本(但不完整(的想法是，我们可能能够重用共享相同目标URI的响应。
HTTP还内置了一个通用机制，用于使存储的响应无效，该响应也集中在目标URI上。
所以，这里有一部分是你需要思考的谜题：当有人向/bananas发送POST请求时，缓存是否应该丢弃带有PDF表示的先前响应？
如果答案是"否"；否"；，那么您需要一个不同的目标URI。这可以是任何对你有意义的事情。例如CCD_ 6。(标识符中使用了多少公共路径段取决于您从相对引用和点段中获得的便利程度。(
如果答案是"否"；是"；，那么您可能需要倾向于使用内容协商。
在某些情况下，答案可能是"；两者"——也就是说具有返回相同表示的多个资源(每个资源具有自己的标识符(
这是一件正常的事情；我们甚至有一种机制来描述哪个资源是"资源"；优选的"；(参见RFC 6596(。
REST并不关心这一点，但HTTP标准关心这一问题。为期望的MIME类型使用accept头是实现这一点的标准方法，所以您做了正确的事情。如果数据相同只是格式不同，则无需将其移动到单独的端点。
媒体类型是表示这一点的最佳方式，但它的一个实际方面是，人们将使用根名词浏览rest API。。。我会对它设置一些创纪录的计数限制，也许GET/banans/export/100可以获得前100个，如果他们真的想要所有的话，可以GET/banas/export/all。