API项目中 官方客户端不再是可有可无的

日期:2016-11-9作者:Zachary Flower

API   API客户端   

【TechTarget中国原创】

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

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

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

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

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

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

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

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

API>更多

相关推荐

  • Google收购Apigee,焦点在于企业本身还是API?

    Axway的Suraj Kumar认为Apigee收购案不一定是件好事。尽管Google也许会像Borg一样行动,这也许预示着Google的态度需要转变。

  • Google的新收购是否意味着API变得更酷了?

    Google对API管理解决方案提供商Apigee的收购,我们应该怎么评价呢?是为了打造一个改变游戏的联盟吗?或者只是技术巨头想尽快吞食市场份额的尝试?

  • API版本化与迁移五大策略

    API版本化和迁移是不得不解决的问题,特别是在应用程序接口和不断变化的业务优先级绑定越来越紧密的当下。但是,如果采取一些关键步骤,改动API就不会造成悲剧。

  • 如何直接从API中查询数据

    每天都有更多公司通过API在Web上发布他们的数据。访问并使用这些数据似乎成了懂得如何编程的“极客”特权。那么从API中查询数据有哪些步骤?

技术手册>更多

  • 敏捷开发技巧指南

    敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。关于瀑布方法和敏捷方法的分析已经探讨过多次,但瀑布方法在某些项目和开发团队中还存在价值。《敏捷宣言》声明指出,个人和交互高于流程和工具。由于开发项目的利益攸关者已经变得越来越分散,遍布在全球各地,甚至经常横跨了几个时区,基于云的开发环境已成为必备之选而非锦上添花。TT SOA在这本技术手册中将介绍敏捷开发的一些技巧以及瀑布方法和敏捷方法的对比,同时还涵盖了云对于敏捷开发所起到的作用。

  • BPEL基础使用技术手册

    BPEL是一门用于自动化业务流程的形式规约语言。 用XML文档写入BPEL中的流程能在Web 服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。在《BPEL基础使用技术手册》中,我们将介绍BPEL流程基础结构、BPEL可以用在哪些方面以及在在Oracle SOA套件中如何用BPEL创建复合服务。

  • XML安全教程

    XML是确保Web服务安全的一个重要因素。XML是因特网以及近来Web服务持续增长和开发的主要支持者。

  • SOA与敏捷开发实战演练

    SOA是一种架构,敏捷是一种方法论,架构和方法论是可以一同使用的,它们本质上是互补的。而且,SOA和敏捷的目标相同,它们都承认(1)变化是必然的(2)组织需要有效地应对变化。所以,我们期望在构建SOA时,能够选择敏捷方法论,反之亦然。本技术手册给出了二者结合的完美之道。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算
【TechTarget中国原创】

在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的投入,但你们的付出在消费者和贡献者眼里是有目共睹的。