如何做到API兼容

发布网友发布时间：2022-04-26 05:31

共1个回答

热心网友时间：2022-06-21 05:24

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上实现。这通常用于解决用户需要一个代码精简的版本时。