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中查询数据有哪些步骤?

技术手册>更多

  • 业务流程管理BPM(更新版)

    业务流程管理(business process management,bpm)不是一个新概念,甚至不是一个新名词。它是从相关的业务流程变革领域,如业务流程改进(bpi)、业务流程重组(bpr)、业务流程革新中发展起来的。流程管理技术也是从早期的工作流管理、eai、流程自动化、流程集成、流程建模、流程优化等技术中发展起来的。

  • 云计算小指南(更新版)

    云计算的概念越来越流行,Amazon、Google和IBM是第一批将云计算引入公众视线的公司。云计算就是新的Web2.0,一种既有技术上的市场绽放。

  • JBoss实用技术手册

    JBoss是一个同时运行Web及EJB的J2EE应用服务器。它是开放源代码的项目,遵循最新的J2EE规范。从JBoss项目开始至今,它已经从一个EJB容器发展成为一个基于的J2EE的一个web操作系统(operating system for web),它体现了J2EE规范中最新的技术,无论是学习还是应用,JBoss为我们提供了一个非常优秀的平台。

  • 2010年SOA现状调查报告

    在2008-2009面临全球性的信贷危机时,SOA的应用依然屹立不倒。即便时下流行语已经被“云计算”所替代的情况下,SOA的运用也没有下降。TechTarget/Forrester Research所做的2010SOA现状调查表明……

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