美文网首页前端web
REST服务与RestfulAPI风格

REST服务与RestfulAPI风格

作者: 无锡愚公坊研发团队 | 来源:发表于2018-08-10 15:32 被阅读0次

    最近团队正在做技术升级,需要用到REST服务,后期接口采用Restful风格,实现动静分离。于是在网上搜罗了一系列资料,结合自己团队的一些情况,总结了一下,有理解的不正确的地方还望大家指出

    本文部分图文摘自于,https://blog.csdn.net/maxiao124/article/details/79897229

    1. Rest来源:

    REST:是一组架构约束条件和原则,REST是Roy Thomes Fielding在他2000年的博士论文中提出的。

    Roy Thomas Fielding是HTTP协议(v1.0和v1.1)的主要设计者、Apache服务器作者之一、Apache基金会第一任主席。

    2. 什么是REST

    REST不是”rest”这个单词,而是几个单词的缩写 REpresentation State Transfer,直接翻译:表现层状态转移,这个翻译不太好理解。网上找到一个比较通俗的说法是:URL定位资源,用HTTP动词(GET,POST,DELETE,PUSH等)描述操作

    3. 什么是Restful

    基于REST构建的API就是Restful风格。

    4. 为什么使用Restful

    (1). 我们团队之前一直使用JSP作为表现层,但是这样的技术限制了我们的开发效率,我们需要将前端组给出静态html页面转换为jsp页面,并且写一些js代码,甚至是一些前端代码。这样会严重限制我们的开发效率,也不能让后端组专注于业务功能的开发,所以目前越来越多的互联网公司开始实行前后端分离。

    (2). 近年随着移动互联网的发展,各种类型的客户端层出不穷,Restful可以通过一套统一的接口为PC、微信(H5)、IOS和Android提供服务,这样的接口不需要前端样式,只提供数据。Restful架构如下:

    举一个实际的例子:

    比如用户愚公币交易记录列表,

          PC网站里需要这个功能,

          Android App里面也需要这个功能,

          IOS App里面也需要这个功能。

    按照我们现有的开发模式,我们就要写了2套(PC和APP端)获取用户说说列表的功能。也就是需要在2个地方都写连接数据库配置信息,查询数据库,可想而知是非常浪费时间和经历的,而且安全性能很差(如果将数据库连接的配置写在Android里面),RestfulAPI就能较好的解决这个问题: (以下接口不存在,仅仅是举例)

    愚公币交易查询 PC: http://******.yugyg.com/user/get YgfMoneyDeal?from=PC

    愚公币交易查询安卓: http://******.yugyg.com/user/getYgfMoneyDeal?from=android

    愚公币交易查询 IOS: http://******.yugyg.com/user/getYgfMoneyDeal?from=ios

    带来好处是只要写一次接口就可以供3个地方同时使用,这样不仅更加安全,快捷,最主要是分工更快速了。一个人专门写接口,另外一个人只需要知道如何调用就可以了,完全不需要知道是如何实现的。

    5. 如何设计Restful风格的API

    RestfulAPI就是由后台(SERVER端)来提供接口,前端来调用。前端调用API向后台发起HTTP请求,后台响应请求将处理结果反馈给前端。也就是说Restful 是典型的基于HTTP的协议。那么RESTful API有哪些特征呢?

    (1).Resource资源,首先是弄清楚资源的概念。资源就是网络上的一个实体、一段文本、一张图片或者一首歌曲。资源总是要通过一种载体来反应它的内容。文本可以用TXT,也可以用HTML或者XML、图片可以用JPG格式或者PNG格式,JSON是现在最常用的资源表现形式。

    (2).统一接口。Restful风格的数据元操作CRUD(create,read,update,delete)分别对应HTTP方法:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源,这样就统一了数据操作的接口。

    (3).HTTP状态码,在REST中都有特定的意义:200,201,202,204,400,401,403,500。比如401表示用户身份认证失败,403表示你验证身份通过了,但这个资源你不能操作。

    (4). 无状态。所谓无状态即所有的资源都可以URI定位,而且这个定位与其他资源无关,也不会因为其他资源的变化而变化。

    Restful 是典型的基于HTTP的协议,HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应,在请求结束后,会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。前面一次请求与后面一次请求没有必然的联系,所以是无状态的。

    TCP/IP要建立一个连接,需要经过三次握手,可以简单的理解为:

    ①.客户端发起连接请求,等待服务器响应 

    ②.服务器接收到请求,确认客户端发起的包,并多返回一个包

    ③.客户端接收服务器发过来的包,并且回复给服务器确认包,至此三次握手完成,连接建立

    握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭连接之前,TCP 连接都将被一直保持下去。所以TCP/IP是有状态的。

    有状态和无状态的区别,举个例子说明一下,例如要查询员工工资的步骤为:

    第一步:登录系统。

    第二步:进入查询工资的页面。

    第三步:搜索该员工。

    第四步:点击姓名查看工资。

    这样的操作流程就是有状态的,查询工资的每一个步骤都依赖于前一个步骤,只要前置操作不成功,后续操作就无法执行。

    如果输入一个URL就可以得到指定员工的工资,则这种情况就是无状态的,因为获取工资不依赖于其他资源或状态,且这种情况下,员工工资是一个资源,由一个URL与之对应可以通过HTTP中的GET方法得到资源,这就是典型的Restful风格。

    (5).将API的版本号放入URL。GET:http://www.xxx.com/v1/friend/123。或者将版本号放在HTTP头信息中,我个人觉得版本号能够较好的控制缓存问题,推荐放在HTTP头信息中。

    (6).过滤信息。如果记录数量很多,服务器不可能都将它们返回给用户。API应该提供参数,过滤返回结果。下面是一些常见的参数:

    ?limit=10:指定返回记录的数量。

    ?current_page=2&showCount=10:指定第几页,以及每页的记录数。

    ?search_type=1:指定筛选条件。

    (7). 规范返回的数据。为了保障前后端的数据交互的顺畅,建议规范数据的返回,并采用固定的数据格式封装。

    {

     "msg":"uri_not_found",

     "code":10001,

     "request":"GET/v2/goods/1227"

    }

    6. 采用Restful风格的API可以方便测试

    SpringMVC项目可以通过整合springfox和swagger-ui来构建API接口文档,整合过程可以参考:

    https://my.oschina.net/wangmengjun/blog/907679

    后台通过规范的写法,通过IP+端口号+项目名/swagger-ui.html来访问生成的API接口文档:

    通过swagger-ui与项目的结合,可以提高前后端配合效率,对接口的管理更加方便,提高开发效率。

    7. REST API版本控制

    随着我们需求的变更,功能的迭代,API的更改是不可避免的。当一个API修改时,可能会新增一个参数,也有可能会修改返回的数据类型,也有可能删除某个函数……

    REST不提供任何特定的版本控制指南,但更常用的方法可以分为3种:

    (1).URL版本控制

    使用URI是最直接的方法,尽管它违背了URI应该引用唯一资源的原则。当版本更新时,还可以保障客户端不会受到影响,如:

    http://******.yugyg.com/v1

    http://******v1.yugyg.com

    版本不需要是数字的,也不需要使用“v[x]”语法指定。替代方案包括日期、项目名称、季节或其他标识符,这些标识符对于开发api的团队来说足够有意义,并且随着版本的变化也足够灵活。

    (2). 使用自定义请求头进行版本控制。

    自定义头(例如,Accept-version)允许您在版本之间保留uri,尽管它实际上是现有的Accept头实现的内容协商行为的副本,如:

    $.ajax({

        headers: {

            Accept-version:v1

        },

        type: "get",

        success: function (data) {

        }

    });

    (3). 版本使用Accept标头

    内容协商可以让您保留一组干净的url,但是您仍然需要处理在某些地方服务不同版本内容的复杂性。这个负担通常会向上转移到您的API接口上,API接口负责确定要发送哪个版本的资源。最终结果往往是一个更复杂的API,因为客户端在请求资源之前必须知道要指定哪个头,如:

    Accept:application/ com.yugyg.v1 + json

    Accept:application

    / json com.yugyg + = 1.0版本

    在实际开发中,API永远不会是完全稳定的。因此,如何管理这种变化很重要。

    相关文章

      网友评论

        本文标题:REST服务与RestfulAPI风格

        本文链接:https://www.haomeiwen.com/subject/bwecbftx.html