在API项目中，有官方支持的客户端才能给API社区传达积极的信息。

没有官方支持客户的API就像是没有方向盘的汽车。可能是辆好车，但是却哪儿也去不了。

当然可以做一个方向盘，但这会是一项耗时的工作而且还会有风险。集成“方向盘”这件事情制造商当然比你更在行了。

虽然承认这一点有点尴尬，但我也曾经是不愿替自己的API项目开发官方客户端的。我们会说：“我们不能所有事情都支持。手上积压的无需学习一门全新语言的工作就已经够多了。”虽然这样的心态不算坏，但却有点误导人。

最重要的是，API不仅仅只是关乎代码了，还与社区有关。开发者之所以“团结在自己喜爱的API周围”，是因为开发API的公司尊重他们的价值，并且跟社区一起让API变得更好。

如果在Java API客户端上认真尝试，并且把它开源出来让更聪明的人改进它的话，那就不会给其他Java开发者造成伤害。

没有官方支持客户端的API就像无源之水，会让API变得很糟糕。预期你的消费者从零开始集成你的API，你所传达出来的讯息是，你的API并不是组织优先要考虑的。官方开源的API客户端表明你的API有更高水平的支持，同时也鼓励你和消费者之间进行开放协作和讨论。

PHP，COBOL，Ruby还是C#?

不幸的是，我们都知道光“有”官方API客户端并没有实质性的作用。有很多事情需要考虑和筹谋，最重要的是该支持多少种语言。

确切的回答要取决于API本身和组织的能力，但最常见的三种要支持的语言是Ruby、PHP和Node.js(尽管Go、Python和Java也非常流行)。

你还应该随时掌握社区的动态。尽管第三方客户端未必需要得到“官方支持”，但无疑可以得到你的组织打上“官方推荐”的标签。这是跟社区互动的一种很好的方式，而且并不需要你承担太多东西。

开源你的API客户端

因为你要用若干不同语言开发多个开源项目，所以知道每一种语言开发和部署的最佳实践至关重要。

比方说，虽然在开发和维护PHP库方面你可能是位大师，但你可能还得重温一下RubyGems或者Node Package Manager这样的服务。开源API项目意味着遵循最佳实践不是可有可无的，因为你是把自己面向社区大部分人开放，要接受他们挑剔的目光。很多情况下，这是很有价值的事情，但如果只是半成品就拿出来说Python库做好了，这样是蒙不了人的。

开源你的API客户端是一件很值得赞叹的事，但你永远都应该确保社区遵循一定的规则。GitHub对执行贡献者指南上有出色的支持，还有一个出色的内置问题跟踪器，但是你的成功之路是无法自动化的。

你的API项目至少应该有一个README文件，里面应该概括了有关的每一条重要信息。考虑以下问题：

如何进行单元测试?

是不是在利用持续集成/持续交付工具，如果是，贡献者如何才能利用这些工具?

项目的授权模式是什么样的?

这些都是很重要的事情，如果处理得好，就可以把一个开源项目引向成功。这一成就反过来也会导致你的官方API客户端的成功。

最后，你的官方API客户端的开发和管理应该是有趣的、能打造社区体验的。尽管这类努力增加了你的团队对API的投入，但你们的付出在消费者和贡献者眼里是有目共睹的。