我正在开发一个 REST API，其中一个调用看起来像/api/1/orders/1234 .默认情况下，结果以 Json 格式返回，并在 AngularJS 的帮助下显示在浏览器窗口中。
在这种特定情况下，我必须生成资源的 PDF 版本，该版本将被打印、签名（手工）并出于法律目的存储。考虑到此调用包含生成报告所需的所有数据，建议的执行此操作方法是什么？
我的猜测是，PDF版本只是资源的另一种格式，只需添加一个查询参数（?format=pdf）就足够了，而且没有那么丑陋。有没有更好的方法（不在乎更难还是更容易实现，特别是服务器端）？
我在任何地方都找不到推荐的方法，所以任何提示都会很好。抱歉，如果这个问题太像"基于意见的问题"。
"正确"的方法是使用请求标头字段Accept: application/pdf，它允许内容协商。
您对api/1/orders/1234?format=pdf的建议可能会奏效，尽管有更干净的解决方案api/1/orders/1234.pdf
根据您是否可以控制客户端（我也编写了我的Perl CLI客户端），我不会为那些不支持完整HTTP规范的客户端而烦恼。只要我们觉得有义务支持糟糕的客户，就不会有升级这些客户的冲动。
处理这种情况的推荐方法是使用内容协商。
当响应传达源服务器通常具有的有效负载信息时表示该信息的不同方式;例如，在不同的格式。出于这个原因，HTTP 提供了以下机制：内容协商。
Apache HTTPD 内容协商文档提供了一些很好的例子（如果不使用 httpd，可以忽略配置细节）。如果您的 API 由应用程序客户端使用，这将很好地工作。
因此，当客户端需要 json 表示形式时，它可以请求
GET /api/1/orders/1234 HTTP/1.1
Host: example.org
Accept: application/json
当客户端需要 PDF 表示形式时，它可以请求
GET /api/1/orders/1234 HTTP/1.1
Host: example.org
Accept: application/pdf
但是，如果您的客户端基本上是浏览器，情况会略有变化，因为当您在地址栏中键入 URL 时，它们通常会发送通用的 Accept 标头。您可以在此处检查常见浏览器（如Firefox，Safari，Chrome，Internet Explorer和Opera）的这些值。
例如，Chrome 会发送以下"接受"标头。
Accept: application/xml,application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8,image/png,*/*;q=0.5
因此，在这种情况下，浏览器所说的是它更喜欢xml和html，如果不是纯文本，png图像或任何其他类型。在这种情况下，它不会告诉您对 json 和 pdf 的任何偏好（并且用户无法使用浏览器轻松指定）。在这种情况下，有两个 URL 可能是合理的，例如/api
/1/orders/1234（或/api/1/orders/1234.json）和/api/1/orders/1234.pdf。因此，您的选择将取决于您预期的客户类型。但是，如果它是同一资源的两种表示形式，则使用HTTP更合适的方法是使用内容协商。