你了解 RFESTful API

一、概述
在没有前后端分离的概念之前，一网站的完成总是“all in one ”，在这个阶段，页面 、数据、渲染、全部在服务端完成，这样出现了弊端是后期的维护，扩展及其痛苦，开发人员同时还必须具备前后的知识，于是到后面前后端思想兴起，后端负责数据，前段负责数据渲染，然后用指定的API格式获取数据，对接展示给用户。
关于API这个问题，就是如何设计出一个便于理解，容易使用的API成了一个问题，然而所谓的RFESTful,就是用来规范API的一种约束。
要深刻去理解，可以从以下几个方面进行理解：
1.每一个URL代表一种资源
2.客户端和服务端之间，传递这种资源的 某种表现层
3.客户端通过四个http（get，post，put，delete）对服务器端资源进行操作。
二、原则

1. c-s 架构
   数据的存储在Server端，Client端只需使用就行，在两端分离的优势就有明显的展示出来了，Client端代码的移植性变强，Server端的扩展性变强，两端互相都不干扰，单独开发实现。
   2.统一接口
   统一接口对于RESTful服务非常重要，客户端只需关注实现接口就可以，接口的可读性强，调用方便。
   REST接口约束：资源的识别，请求动作，响应信息，通过URI标出你要操作的资源，通过请求动作（http method）标识要执行的操作，通过返回的状态码来表示请求的执行结果。
   3.一致的数据格式
   服务端返回的数据格式有（XML Json获取数据）或者直接返回代码，
   4.可缓存
   客户端可以缓存页面的响应内容。因此响应都以隐式或显式的定义为可缓存的，若不可缓存则要避免客户端在多次请求后用旧数据或脏数据来响应。管理得当的缓存会部分地或完全地除去客户端和服务端之间的交互，进一步改善性能和延展性。
   5.按需编码，可以定制代码
   服务端可选择临时给客户端下发一些功能代码让客户端来执行，从而定制和扩展客户端的某些功能。提示：REST架构中的设计准则中，只有按需编码为可选项。如果某个服务违反了其他任意一项准则，严格意思上不能称之为RESTful风格。
   6.无状态
   http请求本身就是无状态的，基于C-S架构，客户端请求要带有充分的信息才能够让服务端识别。请求所需的一些信息都包含在URL的查询参数、header、div，然而服务端是根据请求的各种参数，无需保存客户端的状态，将响应正确返回给客户端。无状态的特征大大提高的服务端的健壮性和可拓展性。
   当然，这种无状态性的约束也是有缺点的，客户端请求都必须带上相同重复的信息确定自己的身份和状态，造成传输数据的冗余性，但这种状态对于性能和使用来说，几乎是忽略不计的。
   三、实例
   url命名规范：
   在RESTful架构中，每个url代表一种资源，所以url中不能有动词，只能有名词，并且名词中也应该使用复数。实现者应使用相应的Http动词GET、POST、PUT、PATCH、DELETE、HEAD来操作这些资源即可
   如果不规范的url，形式不固定，没有意义，不同的开发者还需要了解文档才可以调用
   

2.统一返回数据格式


3.HTTP状态码也是有规律的：

1，请求未成功
2，请求成功、表示成功处理了请求的状态代码。
3，请求被重定向、表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向。
4， 请求错误这些状态代码表示请求可能出错，妨碍了服务器的处理。
5，（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。