为啥RESTFULL如此重要？
本 文我们将讨论REST，它定义了一组体系架构原则，您可以根据这些原则设计以系统资源为中心的Web服务，这是一个非常容易让人误解的概念。本文主要是写 给那些想设计WebService API但却对REST没有十分清晰认识的开发者们。在本文最后会附上一些资源供大家学习，这些资源讲解非常详细。
什么是REST？
表征状态转移（Representional State Transfer），是Roy Fielding（ HTTP 规范的主要编写者之一）博士在2000年他的博士论文中提出来的一种软件架构风格。它并不是一个标准，而是通过表征（Representional ）来 描述传输状态的一种原则。其宗旨是从资源的角度来观察整个网络，分布在各处的资源由URI确定，而客户端的应用通过URI来获取资源的表征。获得这些表征 致使这些应用程序转变了其状态。随着不断获取资源的表征，客户端应用不断地在转变着其状态。
目 前在三种主流的Web服务实现方案中，因为REST模式的Web服务与复杂的SOAP和XML-RPC相对比，更加简洁，越来越多的Web服务开始采用 REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。
让我们来思考一下：
Marcus是一个农民，他有4头牛，12只鸡和3头奶牛。他现在模拟一个REST API，而我是客户端。如果我想用REST来请求当前的农场状态，我仅会问：“State？”Marcus会回答：“4头猪、12只鸡、3头奶牛”。
这是REST最简单的一个例子。Marcus使用表征来传输农场状态。表征的句子很简单：“4头猪、12只鸡、3头奶牛”。
再往下看，看我如何让Marcus用REST方式添加2头奶牛？
按照常理，可以会这样说：Marcus，请在农场你再添加2头奶牛。难道这就是REST方式吗？难道就是通过这样的表征来传输状态的吗？不是的！这是一个远程过程调用，过程是给农场添加2头奶牛。
Marcus很愤怒地响应到：“400，Bad Request”，你到底是什么意思？
所以，让我们重新来一次。我们怎样做到REST方式呢？该怎样重新表征呢？它应该是4头猪、12只鸡、3头奶牛。好，让我们再次重新表征……
我：“Marcus，……4头猪、12只鸡、5头奶牛！”
Marcus：“好的”。
我：“Marcus，现在是什么状态？”
Marcus：“4头猪、12只鸡、5头奶牛”。
我：“好！”
看到了吗？就这样简单。
为什么RPC也不够好？
从逻辑角度来看，为什么会更加青睐REST而不是RPC（Remote Procedure Call，远程过程调用 ），因为它极大的降低了我们沟通的复杂度，通过把表征作为唯一的沟通的方式。无需去讨论过程（添加一头牛？增加一种动物类型？给鸡的数量翻倍还是卖掉所有 猪？）我们只需讨论表征，并且使用这个表征来达到我们想要的目标，很简单，不是吗？我不希望和Marcus的沟通失败，因为我们彼此的理解过程会不一样， 所以只需要知道最后的状态就行。但这仅仅是创建RPC会产生许多问题之一。如果你使用RPC，你需要设计一些程序嵌入到某种结构中。这种结构需要存储参 数、错误的代码、返回值等。我已经看到许多公司这样做，他们设计自己的RPC-结构来实现客户端与服务器端的交互，但却产生许多问题。你为什么要这么做？ 为什么要创建自己的RPC-结构？这样做的好处是？倘若我想要让应用程序使用许多WebService，并且这些WebService带有多个RPC-格 式属性？那么我不得不去开发一些类似这样的东西：
如果你们真的需要RPC，至少要选择一个类似SOAP的标准。
但SOAP也很糟糕
即 使RPC的标准真的很令人痛苦，但我不得不承认ACID事务，一个完整的标准化服务描述性语言SOAP（Simple Object Access Protocol，简单对象访问协议）在某些环境下表现的还不错。尽管如此，SOAP产品的性能开销很大，它是一个巨大的性能杀手。虽然REST不是一个 标准，但在实现RESTful Web服务时可以使用其他各种标准（比如HTTP、URL、XML、PNG等）。
Session更邪恶
你 无需Session！但有人会说：“我想要保存用户购物车里的商品，所以我必须要Session！”不，这样想是错误的！即使没有Session，你也可 以做你任何你想做的事情。你可以只需在URL里封装购物车信息，或者为购物车创建另一个资源，比如“/carts/5235”。
不 需要与客户端进行会话，通过这些操作（指在URL里封装购物车信息，或者为购物车创建另一个资源，比如“/carts/5235”）后，客户端向服务器发 出请求后，哪怕你在服务器上执行卸载平台和操作系统、拆除服务器硬件、重新组装服务器、重新安装操作系统、平台、应用程序备份恢复操作，也不会影响客户 端。
不要强迫客户端保存状态，这样做不仅复杂，而且还会带来许多问题，你应该从你的Web应用程序里删除有状态的东西。
不要重造超媒体
目前，超媒体已经相当普及，我提醒大家，不要再去重新造轮子。这里已经有许多，足够你使用了：
- 采用原子链接规范的超媒体，类似spring-hateoas和spring-data-rest。
- JSON-HAL
- JSON-LD
- ……
其他资源
这里还有一些更加深入的资源供你参考使用：