一个程序化自动交易接口,接口要包含完整的业务功能，而不同程序化自动交易接口,接口之间的业务关联要尽可能的小。还是查询会员的例子，有时查询会员的可能该会员的相关信息要随之发生变化(如状态)，如果这时一条完整的业务流水线，那么就应该在一个程序化自动交易接口,接口里完成，而不应再单独设立程序化自动交易接口,接口去操作完成。就是说一个程序化自动交易接口,接口不应该随着另一个变化而变化或以某几个程序化自动交易接口,接口为前提而存在。
API需要是可测试的，测试不应依赖实现，测试充分的API，尤其是经过了严格的“兼容性整合测试”的API，更能保证在升级的过程中不出现兼容性问题。兼容性整合测试，是指一组测试用例集合，这组测试用例会站在使用者的立场上使用API。在API升级以后，再检测这组测试用例是否能完全符合预期的通过测试，尽可能的发现兼容性问题。
数据格式
有意义的命名
了解客户端原型
保持逐步改善
抽象业务
职责明确
在手机广泛流行的今天，手机应用也随之越来越多，而且成长的速度也非常快。手机应用软件开发实现方式同普通PC软件一样，也分为BS和CS方式。而采用CS方式，在服务器端大多采用程序化自动交易接口,接口的形式提供数据交互(主流数据交互方式有：Json、WebService等)，今天要说的就是如何设计程序化自动交易接口,接口。
有效的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的生命周期结束时能让其平滑的消亡。
一个程序化自动交易接口,接口返回不应该包含过多的数据量，过多的数据量不仅处理复杂，对数据传输的压力也非常大，会导致客户端反应缓慢。过多的数据量很多时候都是程序化自动交易接口,接口划分不明确。
所有程序化自动交易接口,接口的参数格式要求及风格要统不要一个程序化自动交易接口,接口参数是逗号分隔，另一个就是数组;不要一个程序化自动交易接口,接口日期参数是x年x月x日风格，另一个就是x-x-x。
API设计完成以后，需要经过周密的设计评审，评审的重点如下：
了解原型，其实更多是为了帮助你设计程序化自动交易接口,接口时需要提供的数据和结构。但有时当你设计时并没有原型，所以此条并不是必须要求的。但假如设计完程序化自动交易接口,接口后原型出来了，我们也可以拿原型还验证程序化自动交易接口,接口设计是否正确、合理。
分析角度明确
如何做到以上几点，以下是一些总结：
易学习：有完善的文档及提供尽可能多的示例和可copy－paste的代码，像其他设计工作一样，你应该应用最小惊讶原则。易使用：没有复杂的程序、复杂的细节，易于学习；灵活的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必须被正确地使用必须简单必须高性能必须绝对兼容
既然程序化自动交易接口,接口要明白如何从数据库获取、组织数据，就当然要了解数据库结构啦。
FlickrAPI，这里是文档的示例，同时提供了一个非常方便的API测试工具。MediawikiAPIEbayAPI，这里有一个非常详尽的文档示例。
高内聚低耦合
在设计API的时候，一定要避免任何极端的意见，尤其是以下几点：
设计方法
用例驱动，评审前必须提供完善的使用用例，确保用例的合理性和完备性。一致性，是否与系统中其他模块的程序化自动交易接口,接口风格一致，是否与对称程序化自动交易接口,接口的设计一致。简单明了，API应该简单好理解，容易学习和使用的API才不容易被误用，给我们带来更多的麻烦。API尽可能少，如果一个API可以暴露也可以不暴露，那么就不要暴露他，等到用户真正有需求的时候再将它成为一个公开程序化自动交易接口,接口也不迟。支持持续改进，API是否能够方便地通过扩展的方式增加功能和优化。
一些好的API示例：
不是随便一个功能就要有个程序化自动交易接口,接口，也不是随便一个需求就要加个程序化自动交易接口,接口。每新建一个程序化自动交易接口,接口，就要有充分的理由和考虑，即这个程序化自动交易接口,接口的存在是十分有意义额价值的，无意义的程序化自动交易接口,接口不仅增加了维护的难度，更重要是对于程序的可控性的大大降低，程序化自动交易接口,接口也会十分臃肿。因此我放在了第一条。
禁止随意拓展参数
作者小记：程序化自动交易接口,接口设计遵循原则：程序化自动交易接口,接口统一性：避免乱加，重复加后果就是代码变得复杂，难以管理，乃至对数据库造成不必要的消耗或影响。程序化自动交易接口,接口设计不做太多的组合，尽量小而精一方面，降低复杂度，另一方面，三方可以自由组合实现多种所需，且减少双方都开发。尽量预留查询基本元素程序化自动交易接口,接口，查询实体所有字段程序化自动交易接口,接口；组合查询返回详情信息或特定业务，或相对复杂业务，或频繁查询，或其中部分查询没有必要封装程序化自动交易接口,接口的
但是我们为什么还要修改API呢？为了API看起来更加漂亮？为了提供更多功能？为了提供更好的性能？还是仅仅觉得到了改变了时候了？对于用户来说，他们更愿意使用一个稳定但是看起来不那么时髦的API，这并不意味着我们不再改进API了。当糟糕的API带来的维护成本越来越大时，我想就是我们去重构它的时候。
了解数据库结构
把握API的生命周期
与第1条类似，只不过是针对参数而言了。日后拓展程序化自动交易接口,接口可能是难以避免的，但是不要随意就加参数，加参数一定是必要且有意义的，需求改变前首先应考虑现有程序化自动交易接口,接口内部维护是否能满足需求，而不要通过加个参数来方便自己实现需求的难度，因为参数的更变会直接导致客户端调用的变化，容易产生版本兼容性问题。
充分理由
程序化自动交易接口,接口定义的数据格式必须都经过充分考虑，否则会出现数据转换失败或超出长度等错误。如果无法确定，直接设置成字符串是最合适的。
开发API的过程其实就是一个沟通交流的过程。沟通的双方就是API用户和API设计者。
入参格式统一
文章为作者独立观点，不代表股票交易接口观点
相关文章
股民评论