系统接口设计 要求吗（设计接口需要注意哪些）

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

本文目录一览：

• 1、系统接口设计的原则（续）
• 2、（转）对外接口设计规范
• 3、系统概要设计的接口设计
• 4、如何设计系统接口 系统接口设计注意事项
• 5、前后端分离系统接口设计思路

系统接口设计的原则（续）

昨天写到系统接口设计最重要的原则是：

很开心的是大家选了黎叔和Richardson的方案，因为这个方案是最 简单直观 的，并且满足了数据在两个系统的一致性。

还是举昨天的例子，数据在客户系统是这样的：

到我们系统也会生成一样的数据：

我们系统为了生成这条数据，还需要生成一些基础数据：

这个方案的唯一问题是一个正常的SR(一装一卸)被分成了两个SR，一个是提货SR，一个是卸货SR，和我们之前对SR的认知十分不同，除了心里有些小担心之外，暂时也想不出这样会有什么问题。

抛开这个问题，我想用三个词来评价这个解决方案：

（转）对外接口设计规范

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坐标

系统概要设计的接口设计

接口设计包括三个方面：
一、用户接口
用来说明将向用户提供系统接口设计 要求吗的命令和它们的语法结构系统接口设计 要求吗，以及软件的回答信息。
二、外部接口
用来说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。
三、内部接口
用来说明本系统之内的各个系统元素之间的接口的安排

如何设计系统接口 系统接口设计注意事项

共享临时文本文件这种进程之间的通讯方法相比其它方法的优点有很多，下面仅列出我现在能想到的：
·进程之间松耦合
·进程可在同一台机器上，也可跨机，跨操作系统，跨硬件平台，甚至跨国。
·方便调试和监视，只需让第三方或人工查看该临时文本文件即可。
·方便在线开关服务，只需删除或创建该临时文本文件即可。
·方便实现分布式和负载均衡。
·方便队列化提供服务，而且几乎不可能发生队列满的情况（除非硬盘空间满）

前后端分离系统接口设计思路

直接进入正题，总得分为两块，一块是表结构，另一块为实现思路（仅供参考）
一、 表结构

1、 菜单表（right）

字段 类型 注释

id long 主键

name varchar 名称

url varchar 地址

ico varchar 图标

tips varchar 提示信息

parentId long 上级菜单Id

level int 级别:1-3为菜单，4为按钮，5为接口

sort int 排序

2、 角色表（role）

字段 类型 注释

id long 主键

name varchar 名称

desc varchar 描述

code varchar 编码

sort int 排序

3、 角色菜单表（role_right）

字段 类型 注释

id long 主键

roleId long 角色ID

rightId long 菜单ID

4、 用户表（user）

字段 类型 注释

id long 主键

name varchar 姓名

account varchar 账号

password varchar 密码

5、 用户角色表（user_role）

字段 类型 注释

id long 主键

userId long 用户Id

roleId long 角色Id

5、 用户登陆记录表（login_token），过期时间由系统检测

字段 类型 注释

id long 主键

date date 登陆日期

token varchar token

userId long 用户Id

二、 实现思路
1、前端

用户登录，返回token；

根据token查询用户菜单信息，并返回json数据，存入客户端；

根据菜单数据，动态显示菜单，按钮

前端跳转页面，需要在路由中加入前端拦截，读取本地权限数据进行匹配

用户访问接口，后端进行校验
2、后端

编写拦截器，拦截所有url，过滤掉特殊不需要拦截的url;

获取请求中的接口地址，不包含参数;

获取当前请求token，查询用户角色;

根据角色查询所有的接口，拿当前请求的接口进行比对，存在则放行，不存在，则返回错误信息
以上仅为个人设计思路，如有不好的地方，欢迎指正。 关于系统接口设计 要求吗和设计接口需要注意哪些的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 系统接口设计 要求吗的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于设计接口需要注意哪些、系统接口设计 要求吗的信息别忘了在本站进行查找喔。

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