restful架构

CSDN参考
restful是架构的一种约束，给出的一种约束标准 。
REST：Representational State Transfer（表象层状态转变）：

1.每一个URI代表一种资源；
2.客户端和服务器之间，传递这种资源的某种表现层；
3.客户端通过四个HTTP动词（get、post、put、delete），对服务器端资源进行操作，实现”表现层状态转化”。

REST架构的6大原则

1. C-S架构
	数据的存储在Server端，Client端只需使用就行。两端彻底分离的好处使client端代码的可移植性变强，
Server端的拓展性变强。两端单独开发，互不干扰。
2. 无状态
	http请求本身就是无状态的，基于C-S架构，客户端的每一次请求带有充分的信息能够让服务端识别。
请求所需的一些信息都包含在URL的查询参数、header、body，服务端能够根据请求的各种参数，无需保存客户端的状态，
将响应正确返回给客户端。无状态的特征大大提高的服务端的健壮性和可拓展性。
	当然这总无状态性的约束也是有缺点的，客户端的每一次请求都必须带上相同重复的信息确定自己的身份和状态（这也是必须的），
造成传输数据的冗余性，但这种缺点对于性能和使用来说，几乎是忽略不计的。
3.统一的接口
	这个才是REST架构的核心，统一的接口对于RESTful服务非常重要。客户端只需要关注实现接口就可以，接口的可读性加强，使用人员方便调用。
4.一致的数据格式
	服务端返回的数据格式要么是XML，要么是Json（获取数据），或者直接返回状态码
	自我描述的信息，每项数据应该是可以自我描述的，方便代码去处理和解析其中的内容。
比如通过HTTP返回的数据里面有 [MIME type ]信息，我们从MIME type里面可以知道数据的具体格式，是图片，视频还是JSON，
客户端通过body内容、查询串参数、请求头和URI（资源名称）来传送状态。服务端通过body内容，响应码和响应头传送状态给客户端。
这项技术被称为超媒体（或超文本链接）。
	除了上述内容外，HATEOS也意味着，必要的时候链接也可被包含在返回的body（或头部）中，以提供URI来检索对象本身或关联对象。
如请求一条微博信息，服务端响应信息应该包含这条微博相关的其他URL，客户端可以进一步利用这些URL发起请求获取感兴趣的信息，再如分页可以从第一页的返回数据中获取下一页的URT也是基于这个原理。

	JSON为例：
code——包含一个整数类型的HTTP响应状态码。
status——包含文本：”success”，”fail”或”error”。HTTP状态响应码在500-599之间为”fail”，在400-499之间为”error”，
	其它均为”success”（例如：响应状态码为1XX、2XX和3XX）。这个根据实际情况其实是可要可不要的。
message——当状态值为”fail”和”error”时有效，用于显示错误信息。参照国际化（il8n）标准，
	它可以包含信息号或者编码，可以只包含其中一个，或者同时包含并用分隔符隔开。
data——包含响应的body。当状态值为”fail”或”error”时，data仅包含错误原因或异常名称、或者null也是可以的

返回成功的响应JSON:
{
  "code": 200,
  "message": "success",
  "data": {
    "userName": "123456",
    "age": 16,
    "address": "beijing"
  }
}
返回失败的响应json格式:
{
  "code": 401,
  "message": "error  message",
  "data": null
}

4.系统分层
	客户端通常无法表明自己是直接还是间接与端服务器进行连接，分层时同样要考虑安全策略
5.可缓存
	在万维网上，客户端可以缓存页面的响应内容。因此响应都应隐式或显式的定义为可缓存的，
若不可缓存则要避免客户端在多次请求后用旧数据或脏数据来响应。
管理得当的缓存会部分地或完全地除去客户端和服务端之间的交互，进一步改善性能和延展性。
6.按需编码、可定制代码（可选）
	服务端可选择临时给客户端下发一些功能代码让客户端来执行，从而定制和扩展客户端的某些功能。
比如服务端可以返回一些 Javascript 代码让客户端执行，去实现某些特定的功能。

提示：REST架构中的设计准则中，只有按需编码为可选项。如果某个服务违反了其他任意一项准则，严格意思上不能称之为RESTful风格。