当编写一个包（库）的时候，为它提供一个良好的API，几乎与它的功能本身一样重要（好吧，至少你想要让别人使用），但怎么才算一个良好的API呢？在这篇文章中，我将尝试通过比较Requests和Urllib（Python标准库的一部分）在一些经典的HTTP场景的使用，从而提供关于这个问题的一些见解，并看看为什么Requests已经成为了Python用户中的事实上的标准。

- [Requests vs. urllib：它解决了什么问题？](./Requests vs. urllib：它解决了什么问题？.md)

原文：[What problem does it solve?](http://www.curiousefficiency.org/posts/2016/08/what-problem-does-it-solve.html)

对于Python新手来说，Python较令人费解的方面之一就是，当涉及到编写HTTP(S)协议客户端时，标准库的`urllib`模块和流行的（及备受推崇的）第三方模块`requests`之间鲜明的可用性差异。当你的问题是“与HTTP服务器进行通信”时，可用性方面的差异并不是那么明显，但一涉及到额外的需求，像SSL/TLS、鉴权、重定向处理、会话管理和JSON请求/响应主题，差异就明显起来。

想要[记录易用性的差异](http://noamelf.com/2016/08/05/designing-pythonic-apis/)是诱人而完全可以理解的，直到`requests`是"Pythonic" (在2016年), 而`urllib`现在已经不Pythonic了 (尽管被包含在了标准库中)。

虽然当然有那么点因素(例如，内置的`property`是在Python 2.2才添加进来的，而`urllib2`被包含在原始的Python 2.0发布中，因此在其API设计中无法考虑这点)，但是绝大多数的可用性差异涉及到了我们经常忘记问问所使用的软件的一个完全不同的问题：_它解决了什么问题？_

即，`urllib`/`urllib2`和`requests`之间的许多令人惊讶的其他差异可以由它们_解决不同的问题_这一事实，以及较之于Jeremy Hylton在十年前想要解决的问题，现今大多数HTTP客户端开发者所遇到的问题更接近于Kenneth Reitz在2010/2011年设计`requests`用以解决的问题来解释。

引用当前的Python 3 `urllib`包文档：“urllib是一个收集几个处理URL模块的包”。

以及来自Jeremy的添加`urllib2`到CPython的[原始提交信息](https://hg.python.org/cpython/rev/b800e36aed4e)的文档字符串：“使用各种协议，用于打开URL的可扩展库”。

等等，神马？我们只是想写一个HTTP客户端，所以为什么文档谈到一般的URL相关工作？

虽然，对于那些习惯于现代的HTTPS+JSON驱动的交互式web的开发者来说有点奇怪，但是事情为什么会变成这样并不总是清晰的。

在世纪之交，所期望的是，保留丰富多样的数据传输协议，并且为不同的目的进行不同的特点优化，而标准库中最为有用的客户端则是那个可以用来与多种不同类型的服务器（例如HTTP, FTP, NFS等等）进行通信，客户端开发者无需过多担心使用的特定的协议（由URL schema所示）。

然而，在实践中，事情并非如此（大多数是因为严格的防火墙制度，这意味着HTTP服务器是唯一一个可被可靠访问的远程服务），所以，在2016年，人们现在经常拿专用的仅HTTP(S)客户端库的可用性和在获取大多数HTTP(S)特性之前需要专门配置使用HTTP(S)的通用的URL处理库进行比较。

在编写它的时候，`urllib2`是被设计来适合“通用URL处理”这一方孔的方钉。相比之下，大多数的现代客户端开发者在寻找适合“HTTPS+JSON处理”这一圆孔的圆钉 —— 如果你先把角磨圆，那么`urllib`/`urllib2`就会适用，但`requests`则已经是圆的了。

对"它解决了什么问题？"这个不那么明显的问题的回答，会到一个明显得多的后续问题：如果`urllib`/`urllib2`被设计来解决的问题不再常见，而`requests`解决的问题是常见的，那么为什么不把`requests`添加到标准库中呢？

如果我记得没错，在2013年左右(在`requests` 1.0发布后)的一次语言提交中，Guido在原则上认可了这个想法，而在核心开发者团队中，无论是`requests`本身（可能作为一个独立升级组件的捆绑快照），还是带有不一样实现的的API兼容子集，最终都会出现在标准库中，这是一个相当常见的假设。

然而，即使撇开[requests开发者关于此想法的疑惑](https://github.com/kennethreitz/requests/issues/2424)，让`requests`作为标准库组件的一部分，仍然有一些不一般的系统集成问题要解决。

特别是，其中之一是，requests确实更可靠地以跨平台的方式处理SSL/TLS证书是捆绑包含在`certifi`项目中的Mozilla证书捆绑（Mozilla

Certificate Bundle）。这是默认情况下（由于以跨平台的方式获​得对系统的安全证书的可靠访问的困难）的一个明智之举，但它与标准库的安全策略（具体是将证书管理委托给底层操作系统）相冲突。这项策略的目的是解决两个需求：允许Python应用程序访问添加到系统证书存储的自定义机构证书（最值得注意的是，适用于大型组织的私有CA证书），并避免增加当根证书捆绑出于任何其他原因而改变时，需要更新的额外的证书存储到终端用户系统。

这类问题在技术上是可以解决的，但解决它们并不好玩，并且帮助解决它们的人手头上已经有许许多多其他的要求。这意味着，只要大部分的CPython和`requests`开发者将其贡献作为业余时间的活动，而不是专门被雇佣来做的事，那么在这个方面我们可能不会看到太多进展。

如果你像许多人，包括我自己一样，最终好奇为什么在Requests和Urllib之间有如此鲜明的差异。Nick Coghlan在[下面的注释](http://noamelf.com/2016/08/05/designing-pythonic-apis/#comment-2823855721)和下面的一篇博文(标题自解释): [它解决了什么问题？](http://www.curiousefficiency.org/posts/2016/08/what-problem-does-it-solve.html)(Ele注：刚好翻译了这篇的[中文版](./Requests vs. urllib：它解决了什么问题？.md))中分享了它关于这个问题的广阔的视角。

[Requests vs. urllib：它解决了什么问题？](http://www.curiousefficiency.org/posts/2016/08/what-problem-does-it-solve.html) | [中文版](../Others/Requests vs. urllib：它解决了什么问题？.md)