RESTful是什么呢?
HTTP协议的原创作者Roy Thomas Fielding 在他的博士论文中提出一个观点：我写这篇论文的目的，就是希望在符合架构原理的前提下，通过理解和评估以网络为基础的应用软件的结构设计，得到一种功能强，性能好且适用于通信的架构，REST指的是一组架构约束条件和设计原则。
结合于原创作者的观点，现在把符合 REST (Represertational State Transter， 表述性状态转移) 约束的架构称为RESTful架构。RESTful 由于是面向资源接口设计的并且十分的操作抽象，因此能简化开发人员的一些不良设计，并且可以最大限度地利用 HTTP 最初的应用协议设计理念。想要完全了解RESTful，我们就必须掌握资源、表现层和状态转移这3个概念。
1.资源
这里的资源是指网络上的实体或具体信息，如一段文本，一幅图片，一个多媒体文件或一种可以提供的服务。资源是通过URI（Uniform Resource Identifier，统一资源标识符）进行标识的，要想和资源进行交互，只需要访问资源对应的URI就可以了，参考如下：
http://127.0.0.1/v1/news：获取新闻
http://127.0.0.1/v1/group：获取群组列表
http://127.0.0.1/v1/profile：获取个人的详细信息
2.表现层
资源有多种表现形式，具体如何展示是由表现层控制的。例如：数据既可以使用JSON来描述，也可以使用XML来描述。在RESTful服务中，表现层控制着服务器和客户端之间资源的传递形式，比如使用JSON和XML传输文本，而使用JPG，WebP格式传输图片等。当然，通过HTTP传输的数据也可以压缩。
3.状态转移
当我们通过网络和网页发生交互时，就会产生交互式且流程化的信息传递，而在信息传递过程中，必然会有数据和状态的变化，这就是状态转移，状态转移是在表现层之上完成的。在状态转移过程中，我们会用到HTTP的以下4种基本操作。
GET 操作：用来获取资源。
POST操作：用来新建或更新资源。
PUT操作：用来更新资源。
DELETE操作：用来删除资源。
提倡使用的方式可参照：
DELETE http://127.0.0.1/v1/group：删除群组
POST http://127.0.0.1/v1/friends：添加群组
UPDATE http://127.0.0.1/v1/profile：更新个人信息
不提倡或不允许使用的方式如下：
http://api.pr.com/v1/deleteGroup
另外，RESTful要求HTTP状态码必须能够传递穿服务器的状态信息。例如,常用的HTTP状态码200表示成功，500表示服务器内部错误。
RESTful接口测试

RESTful风格的接口和测试工程师之间有这必然的联系，其实想要真正的理解RESTful风格的接口和测试之间的关系，需要先搞明白接口有哪些优点。我们可以简单的举例说明一下，比如组装家具，原材料组装的话需要适配各种样式的螺丝，这时候我们就需要准备各种型号的螺丝刀，所以问题来了，只需要根据螺丝的规则，选择相同的螺丝刀头简单替换就可以了，简单又方便。
通过理解上述的场景后，大致概括为，RESTful指的是一组架构约束条件和设计原则，其本质是为了让访问者一句URI就可以找到资源，然后通过简单的输入和输出完成与服务的交互。
REST所约束的每一个URI都是独一无二的资源，可通过HTTP方法进行资源操作，实现表现层的状态转移。这就像螺丝刀刀头一样，待解决的问题就像螺丝，每一个接口只面向一种特定的资源，而不用管其他接口的处理方式，这样就能够一目了然的知道改用那种螺丝刀刀头固定那种螺丝了，从而降低接口开发的复杂度。
开发同学只需要遵循RESTful规范并按照一定的内部定义开发外部接口，就能形成像螺丝刀刀头一样轻便的接口并对外提供服务。现在的很多项目中，无论是服务器端还是服务器端的调用，还是前端和服务器端的调用，通常会采用RESTful风格来设计接口。
但是对于测试同学来说，RESTful风格的接口使用的仍是之前的访问模式，他们同样是HTTP接口，并且同样可以使用我们之前封装的框架来完成接口测试的任务。但是，RESTful接口测试和HTTP接口测试还有有一些区别的，因为还需要对现有的框架做一些修改，方便与更好的支持RESTful接口测试。
因为Eolink这个工具可以支持RESTful接口做调试，可以使用Eolink工具来简单操作一下，请参照图片示例：

Eolink工具可以实现在线支持不同的RESTful风格的接口，选择协议类型/版本，通过下拉的方式选择不同的请求方式就可以在线编辑一个接口，快速实现接口的请求和返回信息，对于开发和测试工程师来说这是一个快速简便好入门的一个debug接口的好工具。
感兴趣的同学通过该链接可以尝试一下：
https://www.eolink.com/?utm_source=ceshiwo&utm_content=ceshiwo018
现在，大概明白了RESTful接口测试和HTTP接口测试有很大的关系，那么RESTful接口测试和HTTP接口测试又有什么区别呢？两个关键点—数据交互的承载方式和操作方式需要特别关注。
首先来说一下数据交换的承载方式。RESTful风格的接口只要以JSON（JavaScript Object Notation）格式进行数据交换。熟悉SUT（被测系统）使用的Battle系统的同学可能知道，在Battle系统的Readme.md文件中看到过请求正文和响应正文中有关数据不跟的一些定义，这个就是Json。虽然Battle系统不算严格意义上使用RESTful接口，但是在数据交换的承载方式上，Battle系统模仿了RESTful风格。
在讲讲数据交换的操作方式。在Battle系统中，我们仅仅使用了HTTP的GET和POST两种基本操作；但是在RESTful风格的接口中，HTTP的4种进本操作都会被用到，比如，GET操作用来获取资源，POST操作用来新建或更新资源，PUT操作用来更新资源，DELETE操作用来删除资源等。
明白了RESTful风格的接口和普通的HTTP接口的区别之后，我们就会想一想自己得框架需要添加什么内容才能支持RESTful风格的接口。内容的添加方法有两种—借助外力或自行封装。在这里对于第一个RESTful风格的借口来说，数据交换的承载方式是JSON，Battle系统使用的数据格式也是JSON，虽然全部操作都是由参数拼接的过程，但是这些足以能满足需求。
RESRful设计6原则
1.Client-Server：服务端客户端分离，客户端不包括数据，服务端不包括用户状态；
2.Stateless：无状态，让客户端对服务端的操作完全通过表现层来进行；
3.Cache：客户端可以缓存服务端数据；
4.Uniform Interface：统一接口，服务端客户端统一接口；
5.Layered System：分层架构，分层系统，客户端可不直接连接服务端；
6.Code-on-Demand：客户端从服务器获取需要的代码，在客户端处执行；
总得来说
REST架构风格由一组经过选择的架构约束组成，通过这些架构约束在候选架构上产生所期待的架构属性。尽管能够独立考虑其中每一个架构约束，但是根据它们在公共架构风格（common architectural styles）中的来源来对它们进行描述，使得我们理解选择它们背后的基础理论更加容易。