Rest 在API场景中，为什么HTTP内容协商比显式参数更受欢迎？

可用于使客户端和服务器就数据格式和语言达成一致。也许你对我前面的问题（）感兴趣，但没必要读

在开发基于HTTP的API时，这个概念真的有意义吗？（API是最终用户不使用的web服务。它是以编程方式专门调用的。）

内容协商的替代方案是“常规”参数（例如

http://example.org/myService?someParam=1234&lang=en&format=xml

）

大多数客户端框架使调用web服务和发送参数变得非常容易。配置特殊的HTTP头通常要困难得多。使用HTTP内容协商似乎需要更多的工作

同时，没有必要进行谈判。客户机的编程方式将使其知道可用的格式和语言。因此，它只会在这方面作出有效的呼吁，并完全得到它想要的

如果服务器想要拒绝调用，它可以发送应用程序级错误而不是HTTP错误。根据我的经验，应用程序级错误更容易处理。无论如何，你都需要那个代码。您不一定需要解释HTTP错误。你可以把它们都当作一般的失败

内容协商似乎很符合REST哲学，但我更感兴趣的是具体的成本和收益

---

HTTP内容协商在哪些方面优于仅仅添加API参数？

我还没有使用过很多框架，这些框架鼓吹能够使用任何现成的RESTful API。主要是因为如果没有一个非常广泛的配置特性，与任何可能的RESTful实现进行通信是不可行的，而我所看到的这些特性是没有的。然而，这是框架的错误，而不是API的错误

使用请求/响应头对于与任何设计良好的RESTful API进行通信是必不可少的。标头用于发送访问令牌和消息体签名等信息，以及接收集合大小和分页详细信息等信息。为什么不使用一个已经存在的系统来协商内容格式呢？使用现有HTTP规范的全部内容正是REST的目的

关于HTTP错误。。。你为什么对他们一视同仁？404的处理方式应与400的处理方式大不相同，400的处理方式应与409的处理方式大不相同。要么我误解了你，要么我认为你错过了休息的一些关键方面

在开发基于HTTP的API时，这个概念真的有意义吗？（API是最终用户不使用的web服务。它是以编程方式专门调用的。）

是的，现在仍然如此

客户机的编程方式将使其知道可用的格式和语言

这听起来像是将客户机耦合到特定的API，这有点忽略了要点。客户机应该完全理解它自己理解的那些媒体类型，但是为什么它应该知道什么是可用的呢

菲尔丁自己写道：

REST适用于跨多个组织的基于网络的长期应用程序

现在，特别是关于谈判，菲尔丁有一个有趣的观察，在大多数情况下，你会想要

因此

http://example.org/myService?someParam=1234带有适当标题的

，将返回

http://example.org/myService?someParam=1234&lang=en&format=xml

。这可能是通过重定向（这似乎是菲尔丁认为在2006年最合适的机制），也可能只是立即返回协商的表示，并提供返回的表示的标识符

请注意，后一个请求仍然是无状态的——如果您协商到特定资源的方式，或者就像您立即想要的那样，服务器的响应不应该有任何不同。例如，您可能最终与一台服务器协商，并被重新定向到您想要在完全不同的主机上的表示

这意味着服务器无法真正区分协商的客户机和不协商的客户机。您只需将协商资源的标识符直接连接到您的客户机，它就会“工作”

HTTP内容协商在哪些方面优于仅添加API参数

标准化。通过内容协商，我的通用客户机不需要了解api使用的拼写约定。中间组件（例如：缓存）也不需要了解拼写约定

在开发基于HTTP的API时，这个概念真的有意义吗？（API是最终用户不使用的web服务。它是以编程方式专门调用的。）

---

回到这一点：REST是一组选择用于归纳特定属性的架构约束。换句话说，我们正在进行权衡。如果长寿命客户机的优势在您的环境中没有价值，那么支持该用例的体系结构约束将不会发挥其全部作用。

我相信我理解REST，但对我来说它似乎毫无意义。我是否请求

/customers/1234

并发送

接受：xml

，或者我是否请求

/getCustomers？id=1234&format=xml

，似乎并不重要。后者对我来说似乎更简单，并且完成了同样的事情。我试图找出REST的实用价值，在这个问题上，我对内容协商感兴趣。坦白地说，在我看来，这是一种非常有趣的风格。但我愿意被说服。。。您知道一些（公共）API很好地利用了REST吗？我想去看看