精华内容
下载资源
问答
  • API接口设计规范.docx

    2020-02-13 17:20:29
    此文件是API 接口开发规范,结合目前先进的Resful 接口规范整理的一个有利于开发过程中遵循的规范,下载准没错啦!
  • 接口设计规范

    千次阅读 2018-10-19 00:46:14
    文章目录接口设计规范1 接口示例2 基本规范2.1 公共参数2.2 响应数据2.3 字段类型规范2.4 上传/下载2.5 避免精度丢失3 瘦客户端4 拓展性5 安全性6 兼容性7 性能优化 接口设计规范 接口规范化以后,会少很多坑,避免...

    接口设计规范

    接口规范化以后,会少很多坑,避免自己下次再遇到。

    1 接口示例

    接口描述:用户登陆成功后,或进入个人中心时会获取一次用户信息

    URI方法
    /userinfoGET

    请求参数

    名称必填备注
    id用户id

    响应参数

    名称类型备注
    idString用户id
    nameString姓名,例:张三
    ageString年龄,例:20

    json示例

    {
        "code":200,
        "msg":"成功",
        "time":"1482213602000",
        "data": {
            "id":"1001",
            "name":"张三",
            "age":"20"
        }
    }
    

    2 基本规范

    2.1 公共参数

    公共参数是每个接口都要携带的参数,描述每个接口的基本信息,用于统计或其他用途,放在header或url参数中。例如

    字段名称说明
    version客户端版本。1.0.0
    token登录令牌
    os手机系统版本。12
    from请求来源。android/ios/h5
    screen手机尺寸。1080*1920
    model机型。IPhone7
    net网络状态。wifi

    2.2 响应数据

    响应数据统一格式:code、msg、data。

    array类型数据。通过list字段,保证data的Object结构。

    分页类型数据。返回总条数,用于判断是否可以加载更多。

    // object类型数据
    {
        "code":1,
        "msg":"成功",
        "data":{}
    }
    // array类型数据。
    {
        "code":1,
        "msg":"成功",
        "data":{
            "list":[]
        }
    }
    // 分页类型数据。
    {
        "code":1,
        "msg":"成功",
        "data":{
            "list":[]
            "total":"10"
        }
    }
    

    列表类数据接口,无论是否要求分页,最好支持分页,pageSize=Integer.Max即可。

    2.3 字段类型规范

    统一使用String类型。某些情况,统一使用String可以防止解析失败,减少类型转化操作。

    Boolean类型,1是0否。客户端处理时,非1都是false。

    if("1".equals(isVip)){
        
    }else{
        
    }
    

    status类型字段,从1+开始,区别Boolean的0和1。“0”有两种含义,(1)Boolean类型的false,(2)默认的status

    2.4 上传/下载

    上传/下载,参数增加文件md5,用于完整性校验(传输过程可能丢失数据)。

    2.5 避免精度丢失

    缩小单位保存数据,如:钱以分为单位、距离以米为单位。

    3 瘦客户端

    客户端尽量不处理逻辑

    客户端不处理金额

    客户端参数校验规则可以通过接口返回,同时提供默认规则,接口不通则使用默认规则。

    4 拓展性

    图片文案等,与校验规则类似,通过接口返回,并提供默认。

    列表界面

    // 静态列表
    {
        "name": "张三",
        "sex": "男",
        "age": "20岁",
        "nickName": "小张"
    }
    // 动态列表
    {
        "userInfos":[
        {
            "key":"姓名",
            "value":"张三"
        },{
            "key":"性别",
            "value":"男"
        },{
            "key":"年龄",
            "value":"20岁"
        },{
            "key":"昵称",
            "value":"小张"
        }]
    }
    

    多个boolean可以flag替换

    {
        "flag":"7" // 二进制:111,三位分别表示三个boolean字段
    }
    
    long flag = 7;
    System.out.println("bit="+Long.toBinaryString(flag));
    System.out.println("第一位="+((flag&1)==1));
    System.out.println("第二位="+((flag&2)==1));
    System.out.println("第三位="+((flag&4)==1));
    

    5 安全性

    so层,不懂

    6 兼容性

    区分版本

    7 性能优化

    合并接口。一个页面一个接口

    字段简写

    无用字段清理

    图片裁剪

    局部刷新。页面需要的数据,可以用前一个页面带来。

    预加载

    展开全文
  • 军用软件接口设计规范

    热门讨论 2011-12-23 14:23:30
    军用软件接口设计规范,有详细的接口设计文档模板
  • Spring Boot 中 RESTful 接口设计规范

    千次阅读 2020-03-09 16:09:49
    设计接口时,有很多因素要考虑,如接口的业务定位,接口的安全性,接口的可扩展性、接口的稳定性、接口的跨域性、接口的协议规则、接口的路径规则、接口单一原则、接口过滤和接口组合等诸多因素,本...

    在设计接口时,有很多因素要考虑,如接口的业务定位,接口的安全性,接口的可扩展性、接口的稳定性、接口的跨域性、接口的协议规则、接口的路径规则、接口单一原则、接口过滤和接口组合等诸多因素,本篇文章将简要分析这些因素。

    一 规范性建议

    1.职责原则

    在设计接口时,必须明确接口的职责,即接口类型,接口应解决什么业务问题等

    2.单一性原则

    在明确接口职责的条件下,尽量做到接口单一,即一个接口只做一件事,而非两件以上。很多非资深接口设计者,在设计接口时,总认为接口所做的事越多,越牛叉,这是非常严重的错误认识。

    3.协议规范

    在设计接口时,应明确接口协议,是采用HTTP协议,HTTPS协议还是FTP协议,要根据具体情况来定。

    • FTP协议(File Transfer Protocol,简称FTP),是一套标准的文件传输协议,用于传输文件,如.txt,.csv等,一般文件传输,采用FTP协议

    • HTTP协议,适用一般对安全性要求比较低或没要求的业务情景

    • HTTPS=HTTP+SSL,适用于对安全性要求较高的业务情景

    4.路径规则

    由于api获取的是一种资源,所以网址中尽量为名词,而非动词

    /api/v1.0/pruduct/2019/api/v1.0/users/2019

    5.http请求方式

    接口基本访问协议:get(获取),post(新增),put(修改)和delete(删除)

    • get /users:列出所有用户

    • get /users/id:根据id获取用户

    • post /user:新增用户

    • put /user/id:根据用户id更新用户

    • delete /user/id:根据用户id删除用户

    6.域名

    一般地,域名分为主域名和专有域名,主域名适合api长期不变或变化较少的业务,专有域名是解决具体的专有业务的

    以百度举例:

    (1)主域名:www.baidu.com

    (2)产品服务类

    • 百度文库:https://wenku.baidu.com/

    • 百度知道:https://zhidao.baidu.com/

    • 百度资讯:https://zhidao.baidu.com/

    (3)市场活动类

    • 百度公益:http://gongyi.baidu.com

    • 百度logo:http://logo.baidu.com/

    • 百度世界:https://baiduworld.baidu.com

    7.跨域考虑

    在明确域名的情况下,一定要考虑接口是否跨域,以及跨域应采用的技术手段等。

    8.api版本

    对于接口的url,应加版本号http://api.demo.com/v{d}/,如 ,其中d表示版本号,如v1.0,v2.0

    例子:获取产品号为2019,版本号为v1.0的版本号的产品信息

    /api/v1.0/Pruducts/2019

    9.适度过滤信息

    当记录数比较多时(如 SELECT * FROM TBName),因适当添加一些条件对数据进行过滤,如TOP,分页,分组,排序和WHERE条件等

    下面是一些常见的参数。

    • ?limit=100:返回100条数据

    • ?offset=101:从第101条数据开始返回

    • ?page=10:指第10页

    • per_page=100:每页100条数据

    • ?sortby=name:排序字段

    • ?order=desc:降序

    • ?group=groupName:分组

    • ?producy_type=1:筛选条件

    10.返回数据格式

    返回数据格式,一般包括三个字段:

    (1)失败情况(状态码、错误码和错误描述)

    (2)成功情况(标识id,数据对象,状态码)

    11.安全性原则

    接口暴露的考虑,接口并发量的考虑,接口防攻击的考虑,接口跨域的考虑等

    12.可扩展性原则

    在设计接口时,充分考虑接口的可扩展性。

    13.定义api界限

    任何api,从权限上,可归结为匿名api和非匿名api,前者不需要验证,后者需要验证

    14.定义api返回码

    在api设计时,要定好api返回码,如

    • 1 --授权过期

    • 404--未找到资源

    • 500--内部服务器错误

    • 600--账号被锁

    二 反规范性建议

    存在这样一种业务场景:某个接口需要返回多个api接口组合的结果 ,在类似的业务场景下,所设计的接口,具有一定的反规范性。

    1.Request

    2.Responce

    三 实例

    假设存在这样一个一个业务:一个ERP系统,需要提供两个接口,一个是用户访问接口(需要验证),另一个是用户注册接口(不需要验证)。

    根据本篇文章一,二部分的建议,我们来设计满足该业务需求的接口

    (一)定义统一参数

    1.定义统一输入参数

    2.定义统一输出参数

    3.定义统一错误码

    (二)定义接口授权类别

    如下为定义接口授权类别

    (三)用户接口

    1.用户注册

    2.Request

    3.Responce

    4.code示例

    (四)用户登录

    1.登录接口概述

    2.Request

    3.Responce

    4.Code

    展开全文
  • APP接口设计规范

    万次阅读 2016-08-22 16:10:23
    APP接口设计规范 效率 安全 版本兼容性 面向对象设计 数据格式Json 服务端的异常处理 1.效率APP对服务器端要求是比较严格的,在移动端有限的带宽条件下,要求接口响应速度要快,所有在开发过程中尽量选择效率高的...

    APP接口设计规范

    • 效率
    • 安全
    • 版本兼容性
    • 面向对象设计
    • 数据格式Json
    • 服务端的异常处理
    • https协议

    1.效率

    APP对服务器端要求是比较严格的,在移动端有限的带宽条件下,要求接口响应速度要快,所有在开发过程中尽量选择效率高的框架,对数据要求也比较严格,app需要什么数据就传什么数据,不可多传,过多的数据量影响处理速度,最重要的是影响传输效率。接口要规范,以面向对象的思想设计接口。

    2.安全

    接口请求成功或失败,需要有明确的标识符来表示。并且对错误原因进行描述。同时因为客户端可能是多语言的,错误原因应该设计为errorCode,由客户端根据errorCode来显示成对应的语言;此外,不允许出现同一个接口返回不同数据格式的json包;为应对被抓包的风险,客户端和服务端也需要有一套约定的算法加密,可以是对称加密,非对称加密,也可以反复加密,此外,对有必须登录要求的私密性app,比如社交类的,金融类的app,需要在登陆后返回token,所有接口请求都需要带token参数,当有第二只手机登录这个账号,则新生成一个token,旧token失效,失效的请求返回失效的返回code,让客户端退出至登录页面,如果一个账号在固定一段时间里频繁换token,那么就要考虑这个账号被盗的可能性。

    3.版本兼容性

    接口不可能永远不变,它会随着需求的变化而做出相应的变动。接口的变化一般会有几种:
    数据的变化,比如增加了旧版本不支持的数据类型
    参数的变化,比如新增了参数
    接口的废弃,不再使用该接口了
    为了适应这些变化,必须得做接口版本的设计。实现上,一般有两种做法:
    1.每个接口有各自的版本,一般为接口添加个version的参数。
    2.整个接口系统有统一的版本,一般在URL中添加版本号,比如http://api.demo.com/v2
    大部分情况下会采用第一种方式,当某一个接口有变动时,在这个接口上叠加版本号,并兼容旧版本。App的新版本开发传参时则将传入新版本的version。
    如果整个接口系统的根基都发生变动的话,比如微博API,从OAuth1.0升级到OAuth2.0,整个API都进行了升级。
    有时候,一个接口的变动还会影响到其他接口,但做的时候不一定能发现。

    4.面向对象设计

    我们在对接口做设计的时候,要充分考虑客户端的界面显示,比如客户端的界面显示是一个列表,那么json数据格式对应的就应该是[]数据类型,这里需要补充一下,Json的值只有六种数据类型:

    • Number:整数或浮点数
    • String:字符串
    • Boolean:true 或 false
    • Array:数组包含在方括号[]中
    • Object:对象包含在大括号{}中
    • Null:空类型

    像java里面的Date类型,那肯定是需要做转化的
    我是做二手车app的,对于车子面向对象举例,以下有两种设计模式
    这里写图片描述
    我的建议是第一种设计模式,该对象对应的json包为
    {
    “brandName”:”奥迪”,
    “carModel”:”SUV”,
    “emissionStandard”:”国五”,
    “carOwner”:{
    “name”:”张三”,
    “drivingYears”:”5年”,
    “id”:”**”
    }
    }
    这样的设计更加符合客户端MVC的设计模式,如果我们有这样一个功能,点击车主能在二级页面看到车主的信息,那么我们只要将车主的模型传到第二个页面即可。那么这样将大大减少客户端的数据处理时间。

    5.数据格式Json

    服务器返回的数据结构,一般为:
    {
    code:0
    message: “success”
    data: { key1: value1, key2: value2, … }
    }

    code: 状态码,0表示成功,非0表示各种不同的错误
    message: 描述信息,成功时为”success”,错误时则是错误信息
    data: 成功时返回的数据,类型为对象 , 因此,data的返回必须是{}的格式,或者传一个null,如果Object类型变成了String类型,那么肯定是报错的。刚做API的小白程序员就犯这样的错误,当然有经验的是不会出现这种低级错误的

    6.服务端的异常反馈

    服务端的程序在运行的时候,可能因为一个数据的转化或空指针异常什么的,都不能让程序奔溃,需要捕获异常并对异常进行处理,并返回明确的数据状态信息,不管是成功的,还是失败的,都必须要有数据返回给APP客户端,否则,接口的协议失去了所有的意义

    7.https协议

    对于敏感的api接口,需使用https协议
    https是在http超文本传输协议加入SSL层,它在网络间通信是加密的,所以需要加密证书。

    https协议需要ca证书,一般需要交费。

    展开全文
  • JAVA接口规范.doc

    2019-09-19 15:05:19
    APP接口开发规范文档-V1.0,java接口开发规范 查询类接口是指客户端传递一些参数,服务端根据参数依据需求,前往数据库查询需要的结果返回数据的一类接口。 返回类型一般有两种。第一种是返回一个对象,第二种是返回...
  • 微服务RESTful 接口设计规范

    万次阅读 多人点赞 2017-06-29 09:51:28
    1、RESTful发展背景及简介 网络应用程序,分为前端和后端两个部分。当前的发展趋势,就是前端设备层出不穷(手机、平板、...RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。 REST(Representati...

    1、RESTful发展背景及简介


    网络应用程序,分为前端和后端两个部分。当前的发展趋势,就是前端设备层出不穷(手机、平板、桌面电脑、其他专用设备......)。因此,必须有一种统一的机制,方便不同的前端设备与后端进行通信。这导致API构架的流行,甚至出现"APIFirst"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。

    REST(Representational State Transfer)表述性状态转换,REST指的是一组架构约束条件和原则。 如果一个架构符合REST的约束条件和原则,我们就称它为RESTful架构。REST本身并没有创造新的技术、组件或服务,而隐藏在RESTful背后的理念就是使用Web的现有特征和能力, 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深, 但是理论上REST架构风格并不是绑定在HTTP上,只不过目前HTTP是唯一与REST相关的实例。

     

    2、RESTful设计风格


    2.1、推荐格式

    1)url格式:

    http(s)://server.com/api-name/{version}/{domain}/{rest-convention}

    这里,{version}代表api的版本信息。{domain}是一个你可以用来定义任何技术的区域(例如:安全-允许指定的用户可以访问这个区域。)或者业务上的区域(例如:同样的功能在同一个前缀之下。)。{rest-convention} 代表这个域(domain)下,约定的rest接口集合。

    2)参数格式:

    GET采用两种常见格式:

    ① URL参数(更推荐),如:

    https://www.example.com/v1.1?name=‘lk-abc%’&age=’lt-10’

    路径参数,如:

    https://www.example.com/v1.1/employees/{id}

     POST采用两种常见格式:

    ①Json格式包装参数提交
     

    POST  https://www.example.com/v1.1
    Content-Type: application/json;charset=utf-8
    {"title":"test","sub":[1,2,3]}

    ②form表单参数提交

    POST   https://www.example.com/v1.1
    Content-Type: application/x-www-form-urlencoded;charset=utf-8
    title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

    3)返回体格式:

    {"status”: 200,
    "message”:"用户查询返回成功”,
    “document”:”https://www.example.com/doc#userinfo”,
       "data”: {
           "className”: "com.fiberhome.smartas.pricecloud.User”,
            "id”:“1b434wtert564564sdffey32”,
            "name”: "lilei",
            "age”: 18,
            "job”: {
                 "className”:"com.fiberhome.smartas.pricecloud.Job”,
                "id”: “1b434wtert564564sdffeyey”,
                "name”: “微服务架构师”
            }
        }
    }

    2.2、协议

    考虑到服务的安全性,建议使用https作为API的通信协议,当然http也是可以的。

    2.3、域名

    建议将API部署在专有域名下,以此屏蔽消费者对服务提供方的部署细节(可借助于平台的反向代理+路由网关),在服务地图丰富起来之后可以考虑多级域名

    https://api.example.com
    https://example.org/api/

    2.4、版本

    考虑到微服务的平滑升级,可以将API的版本号放入URL,也可以将版本号放在HTTP头信息中,但不如放入URL方便和直观。Github采用这种做法。

    https://api.example.com/v1/

     

    2.5、复数名词路径

    在RESTful架构中,每个网址代表一种资源(resource),所以网址中不能有动词,只能有名词,而且所用的名词往往与数据库的表格名对应。一般来说,数据库中的表都是同种记录的"集合"(collection),所以API中的名词也应该使用复数。

    https://api.example.com/v1/employees

     

    2.6、http协议类型表达资源操作

    HTTP协议里的8种方法,及其他衍生方法,常用的Get、post可以间接的实现其余所有的操作,根据框架和浏览器的兼容性选择性使用。

     

    1)  GET(SELECT):从服务器取出资源(一项或多项)。

    2)  POST(CREATE):在服务器新建一个资源。

    3)  PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。

    4)  PATCH(UPDATE):在服务器更新资源(客户端提供改变的属性)。

    5)  DELETE(DELETE):从服务器删除资源

    6)  HEAD:获取资源的元数据。

    7)  OPTIONS:获取信息,关于资源的哪些属性是客户端可以改变的。

    8)  TRACE:回显服务器收到的请求,主要用于测试或诊断。 

    9)  CONNECT:HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

    10) MOVE: 请求服务器将指定的页面移至另一个网络地址。

    11) COPY: 请求服务器将指定的页面拷贝至另一个网络地址。

    12) LINK: 请求服务器建立链接关系。

    13) UNLINK: 断开链接关系。

    14) WRAPPED: 允许客户端发送经过封装的请求。

    15) Extension-mothed:在不改动协议的前提下,可增加另外的方法。

    GET  https://api.example.com/v1/employees/ 获取所有雇员

     

    2.7、过滤信息

    请求信息应该为集合提供过滤、排序、选择和分页等功能

    1)Filtering过滤:

    使用唯一的查询参数进行过滤:

    GET /cars?color=red 返回红色的cars

    2)Sorting排序:

    允许针对多个字段排序

    GET /cars?sort=-manufactorer,+model

    这是返回根据生产者降序和模型升序排列的car集合

    3)Fieldselection

    移动端能够显示其中一些字段,它们其实不需要一个资源的所有字段,给API消费者一个选择字段的能力,这会降低网络流量,提高API可用性。

    GET /cars?fields=manufacturer,model,id,color

    4)Paging分页

    使用 limit 和offset.实现分页,缺省limit=20 和offset=0;

    GET /cars?offset=10&limit=5

    为了将总数发给客户端,使用订制的HTTP头:X-Total-Count.

    链接到下一页或上一页可以在HTTP头的link规定,遵循Link规定:

    Link:<https://blog.mwaysolutions.com/sample/api/v1/cars?offset=15&limit=5>;rel="next",
    <https://blog.mwaysolutions.com/sample/api/v1/cars?offset=50&limit=3>;rel="last",
    <https://blog.mwaysolutions.com/sample/api/v1/cars?offset=0&limit=5>;rel="first",
    <https://blog.mwaysolutions.com/sample/api/v1/cars?offset=5&limit=5>;rel="prev",

     

    2.8、返回结果为统一的json格式

    一方面,出于平台标准化的API管理,另一方面,遵循微服务的宽进严出设计理念,建议RESTful采用标准的Json格式。

     

    返回结构体

       {   "className”: "com.fiberhome.smartas.pricecloud.User”,
           "id”:“1b434wtert564564sdffey32”,
           "name”: "lilei",
           "age”: 18,
           "job”: {
                 "className”:"com.fiberhome.smartas.pricecloud.Job”,
                "id”: “1b434wtert564564sdffeyey”,
                "name”: “微服务架构师”
            }
        }

    注:

    Object implements Serializable;
    JSONObject.fromObject(json);
    JSONObject.parseObject(text)

     

    2.9、返回结果应该包含状态码

    常见状态码,Http1.1协议完整状态码定义参考地址:

    https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

     

    1)  200 OK - [GET]:服务器成功返回用户请求的数据,该操作是幂等的(Idempotent)。

    2)  201 CREATED -[POST/PUT/PATCH]:用户新建或修改数据成功。

    3)  202 Accepted - [*]:表示一个请求已经进入后台排队(异步任务)

    4)  204 NO CONTENT - [DELETE]:用户删除数据成功。

    5)  400 INVALID REQUEST -[POST/PUT/PATCH]:用户发出的请求有错误,服务器没有进行新建或修改数据的操作,该操作是幂等的。

    6)  401 Unauthorized - [*]:表示用户没有权限(令牌、用户名、密码错误)。

    7)  403 Forbidden - [*] 表示用户得到授权(与401错误相对),但是访问是被禁止的。

    8)  404 NOT FOUND - [*]:用户发出的请求针对的是不存在的记录,服务器没有进行操作,该操作是幂等的。

    9)  406 Not Acceptable - [GET]:用户请求的格式不可得(比如用户请求JSON格式,但是只有XML格式)。

    10)  410Gone -[GET]:用户请求的资源被永久删除,且不会再得到的。

    11)  422Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时,发生一个验证错误。

    12)  500INTERNAL SERVER ERROR - [*]:服务器发生错误,用户将无法判断发出的请求是否成功。

    2.10、返回结果中提供帮助链接

    RESTful API最好做到Hypermedia,即返回结果中提供链接,连向其他API方法,使得用户不查文档,也知道下一步应该做什么。注:Github就是这么做的

    返回体结构

    {"link": 
        {
    	 "document":" https://www.example.com/docs#zoos",
    	 "href":"https://api.example.com/zoos",
    	 "title":"List of zoos",
    	 "type":"application/vnd.yourformat+json"
        }
    }

    2.11、API扩展事项

         1)RESTful API依托PaaS平台治理,需要对API进行认证、授权、参数加密等操作,可考虑在HTTP头部加认证token、调用链指令、状态信息等系列信息。
         2)如PPT所言,API分层,会有内部API和外部API之分,两种API的设计或有不同(甚至是不同协议)。
         3)对于API设计的状态选择,建议为无状态、N次幂等,但后续或存在性能优化问题,http2.0待评测。

    展开全文
  • 【RESTful】RESTful API 接口设计规范 | 示例

    万次阅读 多人点赞 2018-10-28 20:57:24
    核心:面向资源设计的API 解决问题: 降低开发的复杂性 提高系统的可伸缩性 例如:设计一套API,为多个终端服务。 设计概念和准则 网络上的所有事物都可以被抽象为资源 每一个资源都有唯一的资源标识,对资源的...
  • 微服务接口定义规范

    2018-11-09 10:41:20
    微服务接口设计采用Restful风格的接口规范,下面是基于Restful风格要求制订的接口设计规范
  • 开发restful接口应该遵循统一的规范,保持规范的统一才能方便维护和应用
  • RESTful API设计规范

    2019-03-15 10:11:31
    RESTful API设计规范
  • 最近项目中大量使用了Spring Cloud Feign来对接http接口,踩了不少坑,也产生了一些对RESTFUL接口设计的想法,特此一篇记录下。SpringMVC的请求参数绑定机制了解Feign历史的朋友会知道,Feign本身是Netflix的产品,...
  • java api接口规范

    2018-07-20 17:24:16
    java api开发接口规范 包括增删改查 下载 上传等传参 返回方式等
  • 管理系统标准接口设计文档
  • java接口文档规范

    2017-06-01 10:55:27
    文档为md格式
  • 软件开发中,接口设计分析,接口设计方法和所需文档的编制
  • 以太网通信接口电路设计规范
  • 但随着业务需求的不断增长,BFF层的接口也不断增多,接口需要不断升级与优化,需要科学管理,因此BFF接口设计规范应运而生。 好了,闲话不多说,直接看图: 一、基本规范 1.公共参数: 是指基于前端通用属性的公共...
  • 时间推移接口越来越多,服务的规模数量越急剧增加,同时每个服务的接口设计杂乱无章。如名称不同、判断逻辑不同、错误码不同、字段数量或多或少等等,这在一个分布式系统中是非常头疼的事情,往往一个实现需要对接多...
  • RESTful API接口设计标准及规范

    千次阅读 2020-05-24 17:23:46
    这导致API构架的流行,甚至出现"APIFirst"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。 REST(Representational State Transfer)表述性状态转换,REST指的是一组架构约束条件和原则...
  • RESTful API接口设计标准及规范

    万次阅读 多人点赞 2019-01-12 11:42:10
    RESTful发展背景及简介 网络应用程序,分为前端和后端两个部分。当前的发展趋势,就是前端设备层出不穷(手机、平板...RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。 REST(Representational Stat...
  • REST接口设计规范

    万次阅读 2016-12-21 18:03:45
    REST接口设计规范 10 NOVEMBER 2015 URI格式规范 URI(Uniform Resource Identifiers) 统一资源标示符URL(Uniform Resource Locator) 统一资源定位符 URI的格式定义如下: URI = scheme "://" authority "/...
  • 接口规范接口调用指导文档

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 360,799
精华内容 144,319
关键字:

接口设计规范