开发人员:构建API时先自己试试

日期:2016-4-5作者:Zachary Flower翻译:崔婧雯 来源:TechTarget中国 英文

API设计   API管理   

【TechTarget中国原创】

简单地构建一个API是不够的。如果在发布API之前不能“先自己试试”,那么结局就是失败。Zachary Flower详细解释了个中原因。创业公司的开发生命周期必然充满妥协。有太多东西需要完成,但是没有足够的资源保证所有东西都“正确”完成,因此开发人员在恰当的时候必须妥协。不幸的是,为产品构建API与其说是技术决策,不如定义成业务决策更为贴切,这也正是需要妥协的地方。

为已有产品构建API的挑战是,业务需求总是最重要的。为了跟上业务需求的脚步,我们通常被强迫在产品质量上作出让步,这在创业公司应用开发过程中很常见,也绝对是API开发的最差方式。

开发API时最重要的一件事是就是使用它。“Dogfooding”是创业论坛里的流行词汇,用来描述企业规律地使用自己的产品,从而更好服务客户的行为。在创建API时,能够“先自己试试”极其重要,因为其向开发人员提供了一种方式来集成业务的核心功能到自己的产品里。如果这样,或者作为主要产品的一部分,API无法正常工作,那么开发人员,及其用户,注定无法获得良好的用户体验。这会让所有人都感觉很糟糕。

挑战代码基

如果在构建API时不先自己试试,那么可能最终需要管理两个单独的,大部分功能一样的代码基。第一个代码基,主要产品,是大部分开发活动发生的地方。因此,它比第二个代码基,API,更加清晰并且功能更为丰富。

被称为“第二个”代码基的API,会很快成为无主代码。它的更新很繁琐,和实际开发相比更像数据处理的工作,因为大部分工作是从“主要”代码基里拷贝方法出来。因为其特性和bug修复晚于主要产品,这会使得用户——至少坚持在使用的消费者——感到上当受骗,甚至可能感到被开发人员背叛了。

API开发会最终延期,甚至可能完全终止,从而保证团队将更多的资源关注于主要产品上。

正确还是完全不正确

当构建API时,一个很好的规则就是,如果还没有准备好重写所有后台代码从而自己试试API,那么最好避免开发API。要像思考任何新产品那样仔细全面地思考开发API的决策。这样,你才能高效投入到构建两个新产品里,因为不能不使用API。

当API是你自己产品的正式后台时,那么很容易保持代码DRY——不重复自己。特性直接为API而开发,这使得可以立即向客户发布特性。这也使得在将主要产品发布给API用户之前测试这些新特性容易得多。当制造者同时也是产品的用户时,那么所有API上存在的问题都会得到极大的重视。Bug会被立即修复,因为它们影响到所有人。

随着开发人员越来越频繁地使用第三方API,我发现大家都能够指出哪些是核心产品的核心部分,哪些是后来添加的东西。不需要专家就能构建出质量良好的产品,开发人员会主动解决使用产品直接会遇到的问题:这在后来开发的API里就缺失这样的关注。

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

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

企业应用集成(EAI)>更多

相关推荐

  • 如何创建成功的RESTful API设计

    设计好的API是一项困难的任务,存在很多主观指标。哪怕是完全拥抱RESTfulAPI设计并对其问题域拥有完整视图的小型初创企业最终也会出现命名不一致、界面模糊以及无记录语义等问题。

  • 企业应用获得成功不可或缺的力量——API

    毋庸置疑,我们已经进入到CA Technologies一直强调的应用经济时代。但是,企业若想在应用程序领域取得成功,管理好API是其必不可少的一个因素。

  • RESTful API设计给开发人员带来怎样的未来?

    在模块化应用世界里,最为持久的争论莫过于面向服务架构和表述性状态转移之争了。本文探讨这样的争论带来了什么及其背后的原因。

  • API管理:万物互联引发的商机

    无论是数据交流,后端和前端的连接,还是与各种设备的互联,API都如同一条纽带贯穿其中,越来越多的企业正在借助API推动业务新的发展。

技术手册>更多

  • BPEL基础使用技术手册

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

  • 解围应用集成困境指南

    集成是个很老的话题,很多时候在谈及新技术的时候,我们会避而不谈,但集成问题却一直贯穿在企业之中。应用集成就是建立一个统一的综合应用,也即将截然不同的、基于各种不同平台、用不同方案建立的应用软件和系统有机地集成到一个无缝的、并列的、易于访问的单一系统中,并使它们就像一个整体一样,进行业务处理和信息共享。要实现这样的效果并不简单,在这本手册中,我们会为您拨开一些迷雾,更好的解决应用集成所面临的问题。

  • 松散耦合的七个级别

    在软件领域,“耦合”一般指软件组件之间的依赖程度。那么,什么是依赖?各种依赖对耦合度和松散度有多大影响?软件耦合可以发生在许多级别。必须区分生成时(编译时)依赖和运行时依赖。在分布环境中,为了确定系统的耦合程度,必须分析各个级别。下面我们就来具体看一下。

  • SOA开发精彩技巧汇总

    我们精选了2009年最受读者欢迎的技巧类文章,涉及到SOA的多个方面的内容,从最热门的云计算到协作型计算MapReduce;从各类SOA模式到REST战略的创建;从SOA颗粒度的获取到ESB选型技巧等等,尽可能涵盖您所关心的问题。下面让我们看看详细内容。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算