今天，怀着对未来的乐观展望，我宣布 Spring Social 项目正式停用。我非常荣幸能够在过去的八年里参与这个项目。

随着 Spring Security 5 的发布，Spring Social 连接框架（我认为这是 Spring Social 最有价值的部分）提供的许多功能现在已成为 Spring Security 的一部分。事实上，早在三月份的一篇博客文章中，我就分享了如何使用 Spring Security 对客户端 OAuth2 的新支持。随着 Spring Security 继续发展其客户端 OAuth 支持，Spring Social 的连接框架将变得越来越不必要。让 Spring 的 OAuth 功能分散在多个项目中已经没有意义了——是时候为 Spring 开发人员提供一个单一的、一致的 OAuth 体系了。

但是 Spring Social 的 API 绑定呢？

难以维护的 API 绑定

此停用公告还涵盖 Spring Social 的 API 绑定，包括 Facebook、Twitter 和 LinkedIn 的 API 绑定。

Spring Social 的 API 绑定最初只是为了展示如何使用连接框架生成的连接。但随后它们发展壮大，并拥有了自己的生命。

虽然 API 绑定通常对需要与它们服务的 API 交互的应用程序很有用，但它们对于实际使用来说过于庞大、复杂且难以维护。Facebook API 绑定提供了大约 180 个不同的操作，即使很少有应用程序需要超过其中六个操作。

保持 API 绑定与它们服务的 API 同步也已被证明是困难的。随着 API（例如 Facebook 的 Graph API）不断发展，需要重新审视 Spring Social 的 API 绑定（在某些情况下需要完全重写并进行重大更改）以保持与其各自 API 的兼容性。考虑到前面提到的 API 绑定的规模，这需要巨大的开发和测试工作——而这最初仅仅是为了展示如何编写 API 绑定。

最后，现在 Spring Framework 5 为 Spring 开发人员带来了响应式编程模型，因此对 Spring Social API 绑定的响应式对应物有了需求。虽然这当然有可能并且合情合理，但这将需要与现有 API 绑定的大小成比例的工作量，并且基本上会复制非响应式 API 绑定中提供的大多数操作。这将有效地使 API 绑定的规模翻倍，从而使维护这些绑定变得更加困难。

相反，我建议应用程序开发人员编写他们自己的 API 绑定实现。这样，您将能够使用更符合您的应用程序需求且比 Spring Social 提供的庞大 API 绑定更容易维护的 API 绑定。此外，如果您希望在 API 绑定中应用响应式类型，欢迎您这样做。我在三月份发表的文章中建议了一种方法。

Spring Social 的停用

Spring Social 不会立即消失。我打算继续处理一些小错误并根据需要发布维护版本。但是，除非有重大且令人信服的要求，否则不计划发布任何进一步的 Spring Social GA 版本。

从今天起，Spring Social（以及前面提到的 Spring Social API 绑定模块）将继续支持 12 个月，支持期将于 2019 年 7 月 3 日结束。

我衷心感谢所有在过去 8 年里使用并为 Spring Social 做出贡献的人。这是一个有趣的项目，宣布它的最终消亡让我感到些许悲伤。请放心，这不是一个轻易做出的决定。但我鼓励您查看 Spring Security 5 的客户端 OAuth 支持，并继续通过建议和请求请求与我们合作，帮助撰写 Spring OAuth 新篇章。