REST设计风格：你写的 RESTful API 到第几层了?

理解REST

在理解其真正概念前，我们先来明确： REST它的核心思想是面向资源的抽象（相对于RPC就是面向过程抽象），它是一种设计风格的指导，而非具有较强约束的协议。

REST源于Roy Thomas Fielding在2000年发表的博士论文“Architectural Stylesand the Design of Network-based Software Architectures”[1]提出的一种编程思想，并为这种程序设计风格取了一个很多人难以理解，但是今天已经广为人知的名字——REST（Representational State Transfer，表征状态转移）。

如果拆分成独立单词Representational、State、Transfer，我们知道它们分别是表征、状态、转移的意思。但是合在一起，好像又不明白它想要表达的意思了。我们不妨先去理解什么是HTTP（毕竟REST是建立在HTTP之上的），你会发现REST实际上是“HTT”（Hypertext Transfer）的进一步抽象，两者的关系就如同接口与实现类的关系一般。REST是对资源的抽象，何为资源？

资源（Resource）：譬如你现在正在阅读一篇名为《REST设计》的文章，这篇文章的内容本身（你可以将其理解为蕴含的信息、数据）称之为“资源”。无论你是通过阅读购买的图书、浏览器上的网页还是打印出来的文稿，无论是在电脑屏幕上阅读还是在手机上阅读，尽管呈现的样子各不相同，但其中的信息是不变的，你所阅读的仍是同一份“资源”。

然后我们以此文章为资源，来看看表征、状态、转移在阅读文章过程的中含义：

表征（Representation）：当你通过浏览器阅读此文章时，浏览器会向服务端发出“我需要这个资源的HTML格式”的请求，服务端向浏览器返回的这个HTML就被称为“表征”，你也可以通过其他方式拿到本文的PDF、Markdown、RSS等其他形式的版本，它们同样是一个资源的多种表征。可见“表征”是指信息与用户交互时的表示形式，这与我们软件分层架构中常说的“表示层”（PresentationLayer）的语义其实是一致的。

状态（State）：当你读完了这篇文章，想看后面是什么内容时，你向服务端发出“给我下一篇文章”的请求。但是“下一篇”是个相对概念，必须依赖“当前你正在阅读的文章是哪一篇”才能正确回应，这类在特定语境中才能产生的上下文信息被称为“状态”。我们所说的有状态（Stateful）抑或是无状态（Stateless），都是只相对于服务端来说的，服务端要完成“取下一篇”的请求，要么自己记住用户的状态，如这个用户现在阅读的是哪一篇文章，这称为有状态；要么由客户端来记住状态，在请求的时候明确告诉服务端，如我正在阅读某某文章，现在要读它的下一篇，这称为无状态。

转移（Transfer）：无论状态是由服务端还是由客户端来提供，“取下一篇文章”这个行为逻辑只能由服务端来提供，因为只有服务端拥有该资源及其表征形式。服务端通过某种方式，把“用户当前阅读的文章”转变成“下一篇文章”，这就被称为“表征状态转移”。

RESTful系统的六大设计原则

1.客户端与服务端分离（Client-Server）

将用户界面所关注的逻辑和数据存储所关注的逻辑分离开来，有助于提高用户界面的跨平台的可移植性。相较以往的完全基于服务端控制和渲染（如JSP这类）的模式已甚少，一方面代码仓库的便捷性和易管理性成为了敏捷开发的障碍，另一