插件系统接口设计规范（插件接口如何设计）

本篇文章给大家谈谈插件系统接口设计规范，以及插件接口如何设计对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享插件系统接口设计规范的知识，其中也会对插件接口如何设计进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、（转）对外接口设计规范
• 2、接口设计评审规范
• 3、什么是接口文档,如何写接口,有什么规范?
• 4、插件机制详解
• 5、前后端接口对接规范（主要前端内容）.md

（转）对外接口设计规范

1、接口禁止方法重载插件系统接口设计规范，重载会在做服务SLA控制，日志监控等方面带来不便

2、接口注释必须清晰地表达如何使用，接口是同步还是异步，服务内容，参数校验规则（精度、长度、取值范围等），返回值信息，异常情况插件系统接口设计规范；使用场景有要求的需要重点这几个方面描述

a)不同使用场景，在注释中区分描述

b)特定使用场景下的业务规则描述

c)特定使用场景下的注意事项描述

格式上参照注释规范{*}

3、接口返回值中属性禁止使用枚举，如果返回值属性是枚举类型，会为后期升级埋下隐患(由于枚举序列化的特性导致

删除枚举值和增加枚举值都可能导致客户端反序列化失败)，建议提供String类型，取值范围可以通过枚举来告诉客户端

禁止声明方式

建议声明方式

/** 强制还款标志，取值范围见{@link EnforceFlagEnum}*/

private String enforceFlag;

4、接口参数涉及取值范围选择的（比如交易码，渠道类型，身份标识），需提供对应的常量给客户端使用，谨慎使用枚举做入参

唯一性控制属性：a)如接口请求参数包含业务唯一性控制字段，需要对相关字段以及唯一性控制方式进行特别说明

b)若在唯一性控制基础之上，涉及相关业务幂等控制处理，需要进行相关详细描述

5、接口方法确保不对外抛出异常，异常情况需要通过错误码通知客户端，处理失败也需要有返回值，返回值实现可参考EcBaseResult及其子类实现

POM依赖

9、接口返回值中的方法尽量只提供基本属性的get set方法，不要提供有业务规则含义的方法（因为业务逻辑的变化会要求客户端升级jar包版本)

10、操作类的接口务必考虑幂等性控制，因为网络重发，客户端异常等都可能会引起重复调用，严重的可能会引起资损

根据业务约定的部分唯一性字段，对多次请求的数据判断是否重复提交的判断依据，比如通过外部订单号outOrderNo做唯一性控制，在唯一性控制的基础上，对请求中的其插件系统接口设计规范他字段进行判断，

如果全部业务数据（或关键业务数据）和已经落库的数据一致，则请求一次和请求多次都不会对业务处理产生影响，返回结果不变，

如果outOrderNo关联的其他信息与系统已经持久化的数据不一致则提示XXX参数与原先的数据不一致。

11、接口命名统一以Facade结尾，个别的SPI接口可以使用别的结尾词以便更好地表达SPI的要求，SOFA框架系统对外接口统一存放在xxx-common-service-facade

这个bundle下

12、接口必须提供有效的监控日志，配置监控报警规则监控日志输出见日志规范

13、敏感信息：接口返回对象属性字段包含敏感信息，需要做好标识，进行相关提示避免客户端打印到日志中去

金额：接口返回对象属性涉及到金额，需要描述金额的单位以及对应的币种 统一使用支付宝金额类com.iwallet.biz.common.util.money.Money

Money所在jar坐标

接口设计评审规范

本接口设计规范，参考了restfull的部分设计理念。

资源是 Restful API 的核心元素，所有的操作都是针对特定资源进行的。

任何事物，只要有被引用到的必要，它就是一个资源。资源可以是实体(例如手机号码)，也可以只是一个抽象概念(例如价值) 。下面是一些资源的例子：

Github 可以说是这方面的典范，下面我们就拿 repository 来说明。

我们可以看到几个特性：

接口名称应简单明了，望文知意，接口简介中，需描述清楚接口的具体业务功能。

原则上，接口命名规范整体采用“名词”+“动词”形式

接口返回或者操作的是单个资源对象，采用名称的单数形式命名，如：/user/add，/user/del，/user/get

接口返回或者操作的是多个资源对象，采用名称的复数形式命名，如：/users/get

针对同一个接口，根据实际业务需求，为解决接口兼容性问题，可以对接口进行版本扩展，命名规范为“名词”+“动词”+“版本号”形式，版本号采用v1、v2、v3形式命名

例：/user/login ，/user/login/v1

接口返回值，将统一采用如下格式：

{
"sign": "f64b967289ac4d8cbfdc22ad30ec9d09",
"content": "{}",
"timestamp": 1561204602005,
"desc": "成功!",
"code": "000",
"accessToken": "83BAED4DAE9DEF783FDE243F4B5C"
}

sign:返回值签名验签（如果需要）

如遇第三方合作等特殊情况，根据实际情况进行设计。

一个接口只做一件事情

连字符"-"一般用来分割URI中出现的字符串(单词)，来提高URI的可读性，使用下划线"_"来分割字符串(单词)可能会和链接的样式冲突重叠，而影响阅读性。

根据RFC3986定义，URI是对大小写敏感的，所以为了避免歧义，我们尽量用小写字符。

例，针对金额，都统一为amount，而不是有的amount，有的money。

如是对老接口进行改动，需考虑接口的兼容性，包括字段的增减、字段名称调整、字段类型的调整、字段值内容长度的调整，字段值取值范围的调整等。

接口一旦发布就不易修改，要保持兼容性，拼写错误也不能改了，所以要仔细检查拼写。
著名悲剧：unix 的 creat。

creat是一个函数，可以用来创建一个文件并以只写的方式打开。

参数命名最好是定语+名词
比如 fileName, maxSize, textColor，而不是用name、size、colour

不要用生僻单词，也不要用汉语拼音

除非是约定俗成已经被广泛使用的缩写，否则老老实实用完整拼写。

比如 有open就要有close，有login就要有logout，这些单词基本是固定搭配的，使用者就很容易理解。

例，业务需要vip用户，接口不允许设计为isVipUser，而应该设计为获取用户的会员等级接口，/user/level/get，这样保证接口的通用性和扩展性

分页相关接口参数命名统一：

pageSize:每页记录条数

pageNum:当前页数

totalPageNum:总共页数

统一以分为单位进行传递

建议统一以时间毫秒数进行传递，避免前后端或者各种场景下日期格式不统一

什么是接口文档,如何写接口,有什么规范?

含义是：在项目开发中，web项目的前后端分离开发，APP开发，需要由前后端工程师共同定义接口，编写接口文档，之后大家都根据这个接口文档进行开发，到项目结束前都要一直维护。

目的是：项目开发过程中前后端工程师有一个统一的文件进行沟通交流开发。项目维护中或者项目人员更迭，方便后期人员查看、维护。

规范是：以/a开头，如果需要登录才能调用的接口(如新增、修改；前台的用户个人信息，资金信息等)后面需要加/u，即：/a/u；中间一般放表名或者能表达这个接口的单词；get方法，如果是后台通过搜索查询列表，那么以/search结尾，如果是前台的查询列表，以/list结尾；url参数就不说了。

API（Application Programming Interface，应用程序接口）是一些预先定义的接口（如函数、HTTP接口），或指软件系统不同组成部分衔接的约定。用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。

应用程序接口又称为应用编程接口，是一组定义、程序及协议的集合，通过 API接口实现计算机软件之间的相互通信。API 的一个主要功能是提供通用功能集。

API同时也是一种中间件，为各种不同平台提供数据共享。程序设计的实践中，编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，从而提高系统的可维护性和可扩展性。

插件机制详解

插件模式是一种应用非常广泛的模式。我们用的很多软件都拥有自身的插件机制插件系统接口设计规范，通过插件可以拓展软件的功能。另外，插件模式也广泛应用于 web 方面。例如 Webpack、 Vue CLI、UMI、Babel等。

那么插件系统是如何实现的呢？

如上图所示，插件应用的流程很简单：

其中，第 3 步的时候，回去调用插件，调用插件时会在主应用或者状态库中添加一系列的属性和钩子。插件调用完毕后，在主应用中就可以使用这些被插件添加的属性和钩子，以此来拓展应用的功能。

关键地方在于插件的形式及插件接口的设计。

插件的形式多种多样，不同的应用有不同的设计。例如 Webpack 插件是一个对象，必须对外暴露一个 apply 方法；UMI 及 VUE CLI 的插件是函数的形式。
毫无疑问，每种插件系统都提供插件系统接口设计规范了固定的插件 API 供插件开发者使用，插件 API 的设计也是一个重点。

那么现在，我们可以根据以上的流程实现一个简单的拥有插件系统的 Demo。

这里，我们规定我们的插件是一个函数，接收 PluginApi 实例作为参数。

假如我们的应用入口非常简单，实例化主应用类，执行 run 方法，如下所示

现在我们的主应用已经实现。接下来实现我们关键的对外API，即 PluginApi。

至此，我们的插件化机制已经实现。那么接下来，我们来依据我们的插件系统写个插件

那么，现在使用 ts-node 运行index.ts，我们就能看到如下输出：

与我们预计的效果是相同的。

前后端接口对接规范（主要前端内容）.md

前后端分离意味着，前后端之间使⽤ JSON 来交流，两个开发团队之间使⽤ API 作为契约进⾏交互。从此，后台选⽤的技术栈不影响前台。当我们决定需要前后端分离时，我们仍然还需要⾯对⼀系列的问题：

RESTful API 统一约束客户端和服务器之间的接口。简化和分离系统架构，使每个模块独立！

REST即表述性状态传递（英文：Representational State Transfer，简称REST）是Roy Fielding博士在2000年他的博士论文中提出来的一种 软件架构 风格。它是一种针对 网络应用 的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。 REST是设计风格而不是标准。 REST通常基于使用 HTTP ，URI，和 XML （ 标准通用标记语言 下的一个子集）以及 HTML （标准通用标记语言下的一个应用）

统一接口约束定义客户端和服务器之间的接口。它简化了分离的结构，使各部分独立发展。

REST要求状态要么被放入资源状态中，要么保存在客户端上。或者换句话说，服务器端不能保持除了单次请求之外的，任何与其通信的客户端的通信状态。 从客户端的每个请求要包含服务器所需要的所有信息。 这样做的最直接的理由就是可伸缩性—— 如果服务器需要保持客户端状态，那么大量的客户端交互会严重影响服务器的内存可用空间（footprint）。

服务器返回信息必须被标记是否可以缓存，如果缓存，客户端可能会重用之前的信息发送请求。

客户端无需关注数据存储，服务器端无需关注用户界面，提高了前后端可移植性。

客户端不关心直接连接到最终服务器还是连接到中间服务器。中间服务器可以通过启用负载平衡和提供共享缓存来提高系统可扩展性。分层系统也可以执行安全策略。

服务器可以通过传输逻辑来临时扩展或定制客户端的功能。

GET https//domain.com/api/{模块名}/{?菜单名}/{接口名}/:param

说明：

被用于获取资源。不允许对服务器上资源做任何修改操作。

示例：

常用于更新资源。通过请求体携带资源发送给服务器。 注意： 在资源ID由客户端而不是由服务器选择的情况下，也可以使用PUT来创建资源。修改成功返回200，创建成功返回201。 建议使用post进行创建新资源。

常用于创建新资源。创建成功通常返回201。

删除资源。

status说明

---------------------------------------------------------------------------分割线-----------------------------------------------------------

请求方式：POST

参数:说明

返回值：

示例1
正确的

错误的

关于插件系统接口设计规范和插件接口如何设计的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 插件系统接口设计规范的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于插件接口如何设计、插件系统接口设计规范的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。