当前位置:首页 > 设计知识 > 企业官网设计 > 什么是API?如何做到API兼容以及评估API?

什么是API?如何做到API兼容以及评估API?


什么是API?如何做到API兼容以及评估API?
API是程序协同开发的重要保证,API的用户希望API的提供方提供的是一段功能明确、接口明了的程序。更重要的是,用户更期望在程序升级以后,他们能够“不经思考”地升级这些第三方代码。

What’s API?

API的全称是application programming interface。

而很多时候,程序开发者仅仅把函数、类的接口做为API的一部分,而忽略了其他重要的编程接口。

事实上,在前端Javscript编程中常见的API包括:

  • 函数、类接口,包括参数,返回值,函数对外部对象(常常是DOM)的具体操作等
  • 网络接口协议,如和后端交互的JSON、XML数据格式,或者script回调中的函数名
  • 样式以及HTML接口
  • 外部依赖(对浏览器具体特性的依赖)
  • 一些无意泄露的内部实现

越往后的API,越隐晦,越不容易受到重视,但是一旦这些API发生变化,可能会导致调用方出现不符合预期甚至程序直接报错的情况。

Why API cannot be changed?

API是程序协同开发的重要保证,API的用户希望API的提供方提供的是一段功能明确、接口明了的程序。更重要的是,用户更期望在程序升级以后,他们能够“不经思考”地升级这些第三方代码。

一旦上述提到的5个API中的任何一个发生变化,可能会给他们带来巨大的代价,用户需要排查所有调用的代码,需要更改一些协议,需要调整所有与之相关的部分,这些工作对他们来说都是额外的,在预期之外的。如果辛辛苦苦完成这些以后,还在测试过程中发现了相关的bug,那对用户的打击就更大了。

如果API经常发生变化,用户就会失去对这段程序的信任,他们会更倾向自己获得源代码以后,按照自己的需求进行修改,自行维护一个内部的API比调用一个不断发生变化的外部API要容易接受的多,虽然这样做和我们协同开发、模块化开发的初衷是完全相悖的。

最后,我们为什么要修改API呢?为了API看起来更加漂亮?为了提供更多有趣的功能?还是仅仅我们觉得到了改变了时候了?对于用户来说,他们更愿意使用一个稳定但是看起来不那么时髦的API,而不是使用一个很时髦,但是会经常变动的API。在这个问题上,项目开发者是实用派。但这并不意味着我们不再改进API了,在后面,我会具体介绍如何能让API保持稳定的同时,让API持续改进。

Quality of API

在正式说兼容性之前,首先要明确一下,什么是好的API,因为导致API的不兼容的根源总是来自一个想法:“期望通过这次改变把API变得更好”。

容易理解
如果一个API不能让大多数使用者快速学会,这一定不是一个好的API。 比如iOS的滑动解锁,老人和小孩都能都能一次解锁,而Nokia的经典两键解锁,你懂的。

一致性
一致性能大大降低用户的学习和使用成本,用户过去的努力学习,能持续的收效。

容易查找和学习
API必须要有文档,并且介绍清晰,提供尽可能多的示例和可copy-paste的代码,降低用户的使用门槛。

提供简单的方案
API要能解决复杂的问题,提供很多可配置项,但是对于那些最常见的case,如果有一个简单的方案供给用户使用,这样能大大提高API的可用性

保护用户在API上的已有工作
用户过去在调用API、基于API开发所做的工作,这样才能给用户带来价值的同时,不破坏他们过去的劳动成果。

如何保证API的兼容

采用良好的设计思路

在设计过程中,如果能按照下面的方式来进行设计,会让这个API生命更长久

  • 面向用例的设计,收集用户建议,把自己模拟成用户,保证API设计的易用和合理
  • 保证后续的需求可以通过扩展的形式完成
  • 第一版做尽量少的内容,由画册设计公司于新需求可以通过扩展的形式完成,因此尽量少做事情是抑制API设计错误的一个有效方案
  • 对外提供清晰的API和文档规范,避免用户错误的使用API,尤其是避免API(见第一节)靠后级别的API被用户知晓与误用

除此之外,下面还列出了一些具体的设计方法:

  • 方法优于属性
  • 工厂方法优于构造函数
  • 避免过多继承
  • 避免由于优化或者复用代码影响API
  • 面向接口编程
  • 扩展参数应当是便利的
  • 对组件进行合理定位,确定暴露多少接口
  • 提供扩展点

有效的API评审

API设计完成以后,需要经过周密的设计评审,评审的重点如下:

  • 用例驱动,评审前必须提供完善的使用用例,确保用例的合理性和完备性。
  • 一致性,是否与系统中其他模块的接口风格一致,是否与对称接口的设计一致。
  • 简单明了,API应该简单好理解,容易学习和使用的API才不容易被误用,给我们带来更多的麻烦。
  • API尽可能少,如果一个API可以暴露也可以不暴露,那么就不要暴露他,等到用户真正有需求的时候再将它成为一个公开接口也不迟。
  • 支持持续改进,API是否能够方便地通过扩展的方式增加功能和优化。

把握API的生命周期

每一个API都是有生命周期的,我们需要让API的生命周期更长,并且在API的生命周期结束时能让其平滑的消亡。

  • 告诉用户我们是如何设计的画册设计公司,避免误用,提供指导,错误的使用往往是缩短API寿命的一大杀手
  • 提供试用期,API不可能一开始就是稳定,经过试用的API才能有更强的生命力
  • 为API分级:内部使用;二次开发使用;开发或试用中;稳定;弃用API。避免API被滥用的同时,我们可以通过调整API的级别,来扩大其影响力,也能更优雅的结束一个API的生命周期。

保持API的逐步改善

过去我们总希望能将现有的“不合理”的设计完全推翻,然后按照现在“美好”的思路,重新设计这个API,但是在一段时间以后,又会碰到一样的状况,需要再推翻一次。 如果我们没有有效的逐步改善的办法,依靠推翻现有设计,重新设计API只能让我们回到起点,然后重现之前的过程。 要有一套行之有效的持续改善的办法来在API兼容的同时,改善API使之更好。

提高API的可测试性

API需要是可测试的,测试不应依赖实现,测试充分的API,尤其是经过了严格的“兼容性整合测试”(见下文)的API,更能保证在升级的过程中不出现兼容性问题。

兼容性整合测试,是指一组测试用例集合,这组测试用例会站在使用者的立场上使用API。在API升级以后,再检测这组测试用例是否能完全符合预期的通过测试,尽可能的发现兼容性问题。

避免极端的意见

在设计API的时候,一定要避免任何极端的意见,尤其是以下几点:

  • 必须漂亮(API一定要漂亮吗?前文已经说过了)
  • API必须被正确地使用(用户很难理解如何正确的使用API,API的设计者要充分考虑API被误用的情况:如果一个API可能会被误用,那么它一定会被误用)
  • 必须简单(我们总会面临复杂的需求,能两者兼顾的API是更好的API)
  • 必须高性能(性能可以通过其他手段优化,不应该影响API的设计)
  • 必须绝对兼容(尽管本文一直提到如何保证兼容,但是我们仍然要意识到,一些极少情况下会遇到的不兼容是可以容忍的)

一些具体的实施方案

在一个API不可避免要消亡或者改变的时候,画册设计公司我们应该接受并且面对这个事实,下面列举了几种保证兼容性的前提下,对API进行调整的办法:

  • 将API标记为弃用,重新建立一个新的API。如果一个API不可避免要被消亡,这是唯一的办法。
  • 为其添加额外的参数或者参数选项来实现功能添加
  • 将现有API拆成两部分,提供一个精简的核心API,过去的API通过封装核心API上实现。这通常用于解决用户需要一个代码精简的版本时。
  • 在现有的API基础上进行封装,
(注:古柏广告设计-版权所有-转载请注明出处。)
关键词: API兼容  返回上层

品牌热线:137-1020-5050


广州古柏广告策划有限公司

地址:广州市天河区东圃长盛商务大厦B213-215

Copyright©2004-2020 GOOBAI Inc.All rights reserved

粤公网安备: 44010602001481号

备案号:粤ICP备09222445号

GOOBAIAD

服务热线:3160-9080/4000-882-993

业务总监:136-3149-2728(Mr.罗)

Q Q/微信:212210324

与古柏对话

关注古柏