我目前正在使用API，我认为这样做是对REST API的错误实现。
我们有以下端点
当您获得第一个发票时，您将获得所有发票，但如果您获得第二个端点，而没有Accept: Application/json标题，则会从第一个端点获得响应。
提供API的公司说，原因是因为第二个端点可以同时提供JSON和PDF输出，这看起来就像PDF一样
GET v1/{organizationId}/invoices/{guid}/pdf
除此之外，如果发送格式错误的guid，您会收到一个完整的HTML 404错误页面，而不是例如空白页面或错误消息。
总结一下
答案 0 :(得分：0)
有些人不喜欢将基于REST的问题归类为“正确”和“错误”，但无论如何我都会继续：
不，第二个资源应始终返回第二个资源的表示，即发票，而不是发票集合。
是的，完全可以返回同一“事物”的多个表示。发票可以想象地返回json和pdf，并且可以根据“Accept”标题选择正确的发票。
不，它不应该是一个新的“端点”，因为这些“东西”不是“端点”，而是资源。发票是一种资源，json文档只是资源的“表示”。
是的，错误响应可以包含正文，服务器可以轻松发送任何代表。服务器当然应该使用客户端的“Accept”标头来定位自己，但不是必须这样做。
一些评论：不应该GET使用错误的 guid 的发票，因为这些资源应该与收集资源链接。当客户端跟踪链接（应该如此）时，应该无法使用错误的guid链接。
返回完全不同的资源（发票集合而不是发票）是错误的，但是可以对同一资源进行多次表示。如果没有“Accept”标头，则服务器应选择一个，或指示406 Not Acceptable。
一个小问题：mime-type不应该是application/json，因为你怎么知道它是发票呢？它应该是：application/vnd.someprovider.invoice+json。这些天没有人对哑剧类型感到烦恼，但我只是为了完整起见而提到它。