接口管理平台设计（接口管理平台作用）

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

本文目录一览：

• 1、六大接口管理平台，总有一款适合你的！
• 2、App 和 Web 的通用接口该怎么设计
• 3、分布式接口自动化测试平台
• 4、四步，设计成功的知识管理平台

六大接口管理平台，总有一款适合你的！

先聊一聊前端和后端分离的优点。前后端分离优点如下：

其中不可避免的就是定制好接口文档接口管理平台设计，后端工程师要写好单元测试，推荐使用 chrome 的插件 postman 或 soapui或 jmeter，service 层的测试用例拿 junit 写。
但是这种情况对于接口文档管理很不方便，所以下面就罗列一些互联网公司常用的接口文档管理平台。

Swagger是一个大型的API开发者的工具框架，该框架提出了一个编写OpenAPI的规范（命名为OAS），并且Swagger可以跨整个API生命周期进行开发，从设计和文档到测试和部署。
Swagger框架三核心：

YApi部署流程介绍

YApi 是高效、易用、功能强大的 api 管理平台，旨在为开发、产品、测试人员提供更优雅的接口管理服务。它可以帮助开发者轻松创建、发布、以及维护API。除此之外，YApi 还为用户提供了优秀的交互体验，开发人员只需利用平台提供的接口数据写入工具以及简单的点击操作就可以实现接口的管理。特性:

难点：如果需要要执行自动化测试，需要编写脚本。

Eolinker是国内企业级IT研发管理解决方案服务品牌，在线API接口管理服务供应商，致力于满足各行业客户在不同应用环境中对研发管理全生命周期的个性化需求，提供API开发管理（AMS）、开发团队协作、自动化测试、网关（AGW）以及监控（AMT）等服务。
特性：

ShowDoc一个非常适合IT团队的在线API文档、技术文档工具。
随着移动互联网的发展，BaaS（后端即服务）越来越流行。服务端提供API，APP端或者网页前端便可方便调用数据。用ShowDoc可以非常方便快速地编写出美观的API文档。

项目地址： https://www.showdoc.cc

DOClever是一个可视化接口管理工具 ,可以分析接口结构，校验接口正确性， 围绕接口定义文档，通过一系列自动化工具提升接口管理平台设计我们的协作效率。
特性：

DOClever官网： http://www.doclever.cn/controller/index/index.html
DOClever GitHub： https://github.com/sx1989827/DOClever

阿里妈妈前端团队出品的开源接口管理工具RAP第二代，RAP通过GUI工具帮助WEB工程师更高效的管理接口文档，同时通过分析接口结构自动生成Mock数据、校验真实接口的正确性，使接口文档成为开发流程中的强依赖。有了结构化的API数据，RAP可以做的更多，而我们可以避免更多重复劳动。基于RAML的接口定义、文档生成、Mock Server完成了定义和使用的分离，通过一套规范完成的接口定义，可以用不同的工具得到适应不同API管理系统的输出，有更多的可能性，同时保持了核心定义不变。RAP较之于RAML，前者更加集中，所有的定义、文档、mock都在同一个服务中完成，并且实时生效，方便快捷，如果只考虑方便易用，RAP是更好的选择，而RAML显得更加繁琐，更适合于公开的接口定义，方便在各个系统之间流转。

github源码地址： https://github.com/thx/rap2-delos

App 和 Web 的通用接口该怎么设计

1、在接口定义中确定MVC的GET或者POST方式
由于我们整个Web API平台是基于MVC的基础上进行的API开发接口管理平台设计，因此整个Web API的接口接口管理平台设计，在定义的时候，一般需要显示来声明接口是[HttpGet]或者[HttpPost]，虽然有些接口也可以不用声明，但是避免出现类似下面的错误信息，显式声明还是有好处的。
请求的资源不支持 http 方法“POST
例如在基类定义的查找对象接口如下所示。
/// <summary
/// 查询数据库,检查是否存在指定ID的对象
/// </summary
/// <param name="id"对象的ID值</param
/// <returns存在则返回指定的对象,否则返回Null</returns
[HttpGet]
public virtual T FindByID(string id, string token)
如果是增删改的接口，一般需要声明为POST方式提交数据，而且基于安全性的考虑，需要携带更多的参数。
/// <summary
/// 插入指定对象到数据库中
/// </summary
/// <param name="info"指定的对象</param
/// <returns执行操作是否成功。</returns
[HttpPost]
public virtual CommonResult Insert(T info, string token, string signature, string timestamp, string nonce, string appid)
2、动态对象的接口定义
在一般的Web API接口里面，我们可能都会碰到很多简单类型的参数，但是又想让它们以POST方式提交数据，那么我们就可以有两种方法来处理，一种是定义一个类来放置这些参数，一种是采用动态的JObject参数，前者有很多不方便的地方，因为我们不可能为每个接口参数定义多一个实体类，这样可能会有很多难以管理的类定义。如下面是微信API的调用接口案例，我们也需要设置这样的处理规则。
接口调用请求说明
http请求方式: POST（请使用https协议）
https://api.weixin.qq.com/cgi-bin/groups/update?access_token=ACCESS_TOKEN
POST数据格式：json
POST数据例子：{"group":{"id":108,"name":"test2_modify2"}}
那么我们采用JObject是这么样的呢，我们来看接口的定义和处理代码。JObject是Newtonsoft.Json.Linq命名空间下的一个对象。
/// <summary
/// 修改用户密码
/// </summary
/// <param name="param"包含userName和userPassword的复合对象</param
/// <param name="token"用户访问令牌</param
/// <returns</returns
[HttpPost]
public CommonResult ModifyPassword(JObject param, string token)
{
//令牌检查,不通过则抛出异常
CheckResult checkResult = CheckToken(token);
dynamic obj = param;
if (obj != null)
{
string userName = obj.userName;
string userPassword = obj.userPassword;
bool success = BLLFactory<User.Instance.ModifyPassword(userName, userPassword);
return new CommonResult(success);
}
else
{
throw new MyApiException("传递参数出现错误");
}
}
其中我们把JObject对象转换为我们所需要的对象的时候，因为我们没有定义具体的实体类，因此采用了dynamic语法，声明这是一个动态对象，由运行时获取对应的属性。
dynamic obj = param;
这样我们就可以在调用的时候，动态POST对应的JSON对象给Web API接口，而不需要预先定义各种接口参数的类了。
/// <summary
/// 调用Web API接口，修改用户密码
/// </summary
/// <param name="userName"用户名称</param
/// <param name="userPassword"修改的密码</param
/// <returns如果修改成功返回true，否则返回false</returns
public bool ModifyPassword(string userName, string userPassword)
{
var action = "ModifyPassword";
var postData = new
{
userName = userName,
userPassword = userPassword
}.ToJson();
string url = GetTokenUrl(action);
CommonResult result = JsonHelper<CommonResult.ConvertJson(url, postData);
return (result != null) ? result.Success : false;
}
其中GetTokenUrl是根据token和API的地址等参数，构建一个完整的提交地址。我们在上面代码通过
var postData = new
{
userName = userName,
userPassword = userPassword
}.ToJson();
就可以动态创建一个对象，并生成它的JSON字符串，把数据POST提交到对应的API接口里面即可，然后对结果进行对象的转换就算完成了。
3、集合和分页的处理
在很多接口里面，我们都需要用到分页的处理，Web API也不例外，这样可以提交数据检索效率，减少服务器数据处理的压力，同时也提交客户端的数据显示速度。
一般的集合接口定义如下所示（通用性基类接口）。
/// <summary
/// 返回数据库所有的对象集合
/// </summary
/// <returns指定对象的集合</returns
[HttpGet]
public virtual List<T GetAll(string token)
{
//检查用户是否有权限，否则抛出MyDenyAccessException异常
base.CheckAuthorized(AuthorizeKey.ListKey, token);
List<T list = baseBLL.GetAll();
return list;
}
但是这样的返回记录会比较多，一般情况下需要分页，那么分页的处理接口定义如下所示。
/// <summary
/// 根据条件查询数据库,并返回对象集合(用于分页数据显示)
/// </summary
/// <returns指定对象的集合</returns
[HttpPost]
public virtual PagedList<T FindWithPager(string condition, PagerInfo pagerInfo, string token)
分页接口，在这里返回的结果里面，用了一个PageList的泛型类，这个方便我们获取当前的记录及总数，它的定义如下所示。
/// <summary
/// 分页集合
/// </summary
/// <typeparam name="T"对象</typeparam
public class PagedList<T
{
/// <summary
/// 返回记录的总数
/// </summary
public int total_count { get; set; }
/// <summary
/// 列表集合
/// </summary
public List<T list { get; set; }
}
最后整个分页的处理Web API接口实现如下所示。
/// <summary
/// 根据条件查询数据库,并返回对象集合(用于分页数据显示)
/// </summary
/// <returns指定对象的集合</returns
[HttpPost]
public virtual PagedList<T FindWithPager(string condition, PagerInfo pagerInfo, string token)
{
//检查用户是否有权限，否则抛出MyDenyAccessException异常
base.CheckAuthorized(AuthorizeKey.ListKey, token);
List<T list = baseBLL.FindWithPager(condition, pagerInfo);
//构造成Json的格式传递
var result = new PagedList<T() { total_count = pagerInfo.RecordCount, list = list };
return result;
}
最后客户端调用分页的Web API代码如下所示。
/// <summary
/// 根据条件查询数据库,并返回对象集合(用于分页数据显示)
/// </summary
/// <param name="condition"查询的条件</param
/// <param name="pagerInfo"分页实体</param
/// <returns指定对象的集合</returns
public virtual List<T FindWithPager(string condition, ref PagerInfo pagerInfo)
{
var action = "FindWithPager";
string url = GetTokenUrl(action) + string.Format("condition={0}", condition);
var postData = pagerInfo.ToJson();
List<T result = new List<T();
PagedList<T list = JsonHelper<PagedList<T.ConvertJson(url, postData);
if (list != null)
{
pagerInfo.RecordCount = list.total_count;//修改总记录数
result = list.list;
}
return result;
}
4、混合框架界面整合Web API接口
在整个Web API的平台构建以及在混合框架的整合过程中，我把各个模块还是遵循相对独立的方式进行开发和整合，它们实现了从直接访问数据库、以WCF服务获取数据，以及通过WebAPI调用方式获取数据几种方式的统一，从而实现了整个混合框架的高度整合。
整个混合框架的核心是以相对独立的方式，整合各个可重用的模块，我们可以遵循一定的基础上，快速构建统一的应用平台。
搭建完毕的整个WebAPI平台，其中包括了服务端内容，以API控制器的方式，发布了对应的Web API接口。
在每个混合框架的独立模块里面，我们封装了对应的Web API客户端调用处理，从而实现了Web API的调用方式。
在Win10下，使用Web API模式运行混合框架，获得的主体界面效果如下所示。
独立模块权限管理系统界面如下所示。
系列文章如下所示：
Web API应用架构在Winform混合框架中的应用（1）
Web API应用架构在Winform混合框架中的应用（2）--自定义异常结果的处理
Web API接口设计经验总结
Web API应用架构在Winform混合框架中的应用（3）--Winfrom界面调用WebAPI的过程分解
Web API应用架构在Winform混合框架中的应用（4）--利用代码生成工具快速开发整套应用
Web API应用架构在Winform混合框架中的应用（5）--系统级别字典和公司级别字典并存的处理方式

分布式接口自动化测试平台

基于之前开发过自动化框架，在接口自动化测试平台上做了全新的探索和设计，在落地性，效益性，业务性等方面做了进一步思考和优化。

从系统需求设计 + 技术框架选型 + 数据表结构设计 + 后端开发 + 前端开发 + 镜像打包部署 + docker 容器化上线，都由我一个人独立设计开发完成的，挑战很大，但是能顺利完成，也算是给自己 2020 年一个满意的答卷，当然更满意的其实是打开了自动化测试平台新世界的大门。

1、接口管理，添加和维护功能。

2、支持用例跳过功能、任务消息提醒（针对当前任务公司所有成员）

3、更丰富的用例断言类型。

4、支持定时任务，在任务管理中分布式执行我的所有接口用例，目前支持crontab表达式和interval间隔时间两种方式调度定时任务。

5、更漂亮、详细的报告展示，快速发现失败接口用例。

6、成员管理，前后端都引用了角色权限管理；前端页面无法访问成员管理、发布成员消息通知等，后端：editor角色无法进行新增、修改、删除功能操作

7、新增业务测试功能 - 多接口实现一个业务流程

8、新增用例前置功能（用例后置功能目前使用上并不灵活，后续解决这个问题，并且更新sql校验功能）

9、用例逻辑处理内置函数功能

10、前端兼容Chrome浏览器、手机端部分页面做了适配（其他浏览器暂未测试）

整个平台后端使用 Python 开发，前端使用 vue 框架，采用前后端分离。

任务结果查看

断言功能

用例前置后置调试功能

报告详情

四步，设计成功的知识管理平台

摘要：成功的知识管理平台是如何设计出来的？带你深入了解！

企业知识管理平台属于运营型系统，应用行政手段强制推行很难获得成功。在设计时最重要的就是面向用户进行价值创造。只有让用户觉得愿用、好用、享用，再配合运营手段，才有可能达到业务目标。

面向用户进行价值创造主要分为用户分析、动机设计、交互设计、视觉设计四步。

1. 用户分析

负责人：

需求调研负责人

目标用户志愿者

关键交付件：

需求文档（使用场景描述）

常用方法：

用户研究；

用户画像；

现场沟通；

数据分析；

场景分析…

关键点：

用户分析是用户价值创造的基础。如果不了解用户是谁，就无法进行针对性设计，后续的步骤就更加无从谈起。用户分析，主要从用户的心理、生理、社会特征、经验、认知程度、从事职业等维度进行分析。

此处的用户并不单单指直接使用平台的人，还包括运营人员，管理人员及领导等。进行用户分析时，需要统一考虑。用户分析主要分为四步：

1）寻找潜在用户群 ：先对企业内不同的用户群进行分类，如研发类、市场营销类等，分别找到相应的接口人，通过沟通等方式获取其基本信息。

2）归纳目标场景 ：将潜在用户群提出的场景，根据头脑风暴、调研等方法，得出可能的目标列表并进行归纳。如：研发用户群，想要在启动新项目时，能够看到其它相关项目的历史经验等...

3）选定目标用户及场景 ：根据这些用户群提出的场景，按照价值高低、积极性、满足度三个角度来进行排列，优先选取高价值、高积极性、高满足度的用户群及场景定为目标用户及目标场景。

4）站在项目角度整体考虑 ：将目标用户及目标场景排序后，从项目资源情况、项目时间计划、整体定位规划等因素筛选最重要的场景进行规划。

对用户进行充分的分析后，就能根据情况针对性的进行用户设计。包括用户动机设计、用户交互设计、用户视觉设计。

2. 动机设计

负责人：

产品经理、

需求调研负责人

运营负责人

关键交付件：

平台规划整体方案

运营方案

常用方法：

头脑风暴

同类产品分析

业务分析

用户心智模型…

关键点：

用户为什么要用你的产品？产品一定要满足用户某种需要才有可能获得成功。无论是规避损失，或者是追求卓越，都会形成一种驱动力，这就是用户动机。针对用户动机设计，具体有三个层面：

1） 产品定位层面 ：为了让产品本身能够让用户产生动机，满足需求。通常在基于用户分析中将用户归类，提炼某类用户当前急迫的需要和面临的难题，指导产品功能开发和创新。

案例：知识管理系统中，如果把知识库定义为事后收集归档的工具，那就是在给用户增加负担。但如果把知识库重新定义为用户在业务运行过程中文件的自然留存工具。把相应功能融入到社区、专题及各个具体业务场景中，让用户更专注与业务本身，反而会更为有效。比如针对问题的讨论、针对某项目的收割等，将知识库隐藏在业务功能背后，提供服务与支撑。让用户通过使用平台能够更好的达成业务目标，在此基础上，通过其背后的逻辑达到设计者的目的，会更有利于平台获得成功。

2） 产品功能层面 ：即使产品定位精准、长远能够解决用户迫切问题，但有时也并不能得到很好的使用。因为用户往往受习惯等因素影响，在动机转换成行动之间，还缺乏一定的诱因刺激。因此需要在产品功能层面也进行一些诱因的设计。诱因设计主要包括目标、规则、关系、反馈四部分。通过设计诱因，来让产品在使用过程中产生一个个带有粘性的功能点，使动机顺利的转换为行为，并在长期使用过程中行程习惯，以保证产品目标的达成。

案例：360在开机时的提示，就是一个很好的诱因。通过弹出“您打败了10%的用户”提示，加上“一键优化”的醒目按钮，给用户设定了一个清晰的目标、简明的规则、将用户置身于群体关系竞争对比中，并给出了及时的反馈指引，从而人为的制造了一个清理电脑的诱因。同样的例子还有运动APP的步数排行榜、用户注册的新手任务、签单抽奖等等。都是通过在功能上植入一个个诱因，促使用户行动并使之行成习惯的做法。

3） 产品周边层面 ：用户需求只有在达到一定强度时，才会触发行动，成为动机。但如果用户需求强度不足，对于用户的短期利益不大，而且产品本身很难让用户产生动机时，就需要用到产品外部的动机设计了。常见的产品外部层面动机设计包括激励机制、内容营销等运营方式。

案例：滴滴打车，在初期车辆不多的情况下，用滴滴的便利性并不比路边拦车高。但设计者明白如果通过运营手段，对用户进行激励，使之产生习惯。那么随着用户数量增多，加盟的车主也会更多，便利性就会提高，就会有更多的用户使用，在网络效应下，就足以变成颠覆传统的新一代出行模式。因此滴滴先后投入巨额的运营费用做双向补贴等运营活动，时至今日，已经变成用户超过4.5亿，每天订单高达2500万的出行平台。当产品很难在其本身上促进用户动机时，通过外部的运营来促使用户转化行为，也是一种重要方式。

用户动机设计，就是通过产品定位、产品功能、产品周边几个层面来促使用户动机转换为行动。这种设计解决了”用户为什么要用你的产品”这个问题。让产品从能用变为了用户“愿用”。

3. 交互设计

负责人：

产品经理

系统架构师

关键交付件：

架构设计方案

低保真交互原型设计方案

常用方法：

信息架构

流程图

关系图

功能模块关系图

框架原型…

关键点：

用户交互设计，是以用户为中心，来定义产品在特定场景下的交互反应方式。用户交互设计主要分为两个层面：

1）业务流程 ：通过将平台内各角色、各功能进行分类，利用信息架构等方式，站在用户的角度，从功能入口开始设计用户操作流程。例如，在设计知识库时，需要考虑有几种类型的知识，具体场景中他们分别如何被使用。用户更适合通过搜索来查找，还是更适合通过树状分类来筛选。选择一种方式的同时也要兼顾其它场景的实现。使系统能够既运行顺畅又能稳定的支撑所有情况。

2）界面布局 ：按照用户的认知习惯，来对操作界面及交互来进行设计，通过利用静态布局、动态效果等方式使用户在操作时更加顺畅。例如：在输入类界面中，通常会把选择框放到一起，输入框放到一起，以降低用户在鼠标和键盘之间切换的频率，以此来提高效率。界面及设计有很多通用的原则可供参考，如：费茨定律、席克定律、7±2法则、格式塔原理、泰思勒定律、防错原则、奥卡姆剃刀原则等。

通过交互设计，可以使使用者更好的使用产品达成目标，让产品从可用，变为易用。

4. 视觉设计

负责人：

产品经理

视觉设计

运营负责人

关键交付件：

高保真视觉设计方案

品牌方案

常用方法：

色彩搭配

人性化提示语

UI规范…

关键点：

软件系统中的视觉设计，更多是视觉传达设计，也就是针对被传达对象来进行表现，而并不体现设计者本身的视觉诉求。因此，在软件中的用户视觉设计，需要具体考虑业务场景，脱离业务场景的美观是没有生命力的，用户体验更是无从谈起。在用户视觉设计中，主要有三步，分别是场景理解、感知认识、统一设计。

就是需要从用户的场景出发，理解用户在该场景下使用各功能的频率，在整个流程中的切换方式及移动的距离等。通过对感知的认识与理解，如：各种颜色的意义、各种位置的隐喻，各种符号的象征等，来产出用户可识别的形状、布局、尺寸、色彩等具体的设计稿。

案例：企业官网通常属于展示型系统，用户场景仅仅是浏览页面，用户在网站导航目录与具体内容页面之间进行切换，因此一般的设计风格都较为简约，根据企业行业、性质，配色都较为商务。但企业内的知识管理平台属于交互型系统，用户的使用场景更多的是协作与互动，因此设计风格就需要更活泼，配色更鲜艳，要有明显的对比来进行功能引导。

每种系统根据自己的定位，都需要贴身制定不同的视觉设计。只有通过这种方式进行的视觉设计，才是视觉与体验统一的，才具备真正的价值。否则，就谈不上视觉设计，只是关注美观，而考虑实际场景，仅仅是美工作图而已。

通过针对用户场景的视觉设计，可以让用户在使用平台的同事，享受到美的体验。让产品从可用，变成用户“享用”。

总结

企业内知识管理平台设计，一定要围绕用户进行价值创造。从用户分析开始，通过用户动机设计，让用户“愿用”，通过用户交互设计，让用户“易用”，通过用户视觉设计，让用户“享用”。也唯有如此，才能打造出真正成功的企业知识平台。

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

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