本篇文章给大家谈谈系统接口设计怎么做,以及系统接口设计案例对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
今天给各位分享系统接口设计怎么做的知识,其中也会对系统接口设计案例进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!
本文目录一览:
前后端分离系统接口设计思路
直接进入正题,总得分为两块,一块是表结构,另一块为实现思路(仅供参考)
一、 表结构
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,查询用户角色;
根据角色查询所有的接口,拿当前请求的接口进行比对,存在则放行,不存在,则返回错误信息
以上仅为个人设计思路,如有不好的地方,欢迎指正。
系统接口设计的原则(续)
昨天写到系统接口设计最重要的原则是:
很开心的是大家选了黎叔和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坐标
如何设计系统接口 系统接口设计注意事项
共享临时文本文件这种进程之间的通讯方法相比其它方法的优点有很多,下面仅列出我现在能想到的:
·进程之间松耦合
·进程可在同一台机器上,也可跨机,跨操作系统,跨硬件平台,甚至跨国。
·方便调试和监视,只需让第三方或人工查看该临时文本文件即可。
·方便在线开关服务,只需删除或创建该临时文本文件即可。
·方便实现分布式和负载均衡。
·方便队列化提供服务,而且几乎不可能发生队列满的情况(除非硬盘空间满)
VB学生信息管理系统中的用户接口设计怎么做
可以使用3张表来实现用户,user用来存放用户的姓名,密码,描述等,有一个关键字FUserID用户组,usergroup用来存放用户组的名称,描述,有一个关键字FUserGroupID关系表,relation用来存放用户与用户组的关联,关联FUserID,FUserGroupID注册的时候把用户信息存放到表user中,用户组信息存放到表usergroup,两者关系存放在表relation在用户登录的时候与user表中的数据进行比较,如果用户名和密码多正确,允许登录系统同时得到他的用户组,以便判断后面的系统模块是否拥有权限去操作如果更负责一点的话,可以加一个权限表,把系统的所有模块多和权限进行关联每一个用户建立的同时再分配权限,操作时多进行权限的判断
关于系统接口设计怎么做和系统接口设计案例的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。
系统接口设计怎么做的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于系统接口设计案例、系统接口设计怎么做的信息别忘了在本站进行查找喔。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
暂时没有评论,来抢沙发吧~