催收系统接口设计规范（催收系统接口设计规范最新）

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

本文目录一览：

• 1、（转）对外接口设计规范
• 2、接口设计评审规范
• 3、什么是接口文档,如何写接口,有什么规范?
• 4、restful api接口规范是什么？

（转）对外接口设计规范

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

restful api接口规范是什么？

REST（REpresentationStateTransfer）描述了一个架构样式的网络系统，比如web应用程序。

一般依赖于HTTP认证，HTTP认证有几种：basic，digest，token，这些都有标准的实现的开源包需要主要的是这个认证的帐号跟你业务的帐户实际是不一样的。REST属于webService一种，安全是后台服务的安全，因此不需要实际的业务帐号，通常是系统keyStore证书库里的账户。

RESTFUL特点包括：

1、每一个URI代表1种资源。

2、客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

3、通过操作资源的表现形式来操作资源。

4、资源的表现形式是XML或者HTML。

5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。

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

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