REST 本身是设计风格而不是标准。REST 谈论一件非常重要的事，如何正确地使用 Web 标准 ，
REST定义了应该如何正确地使用（这和大多数人的实际使用方式有很大不同）Web标准，例如HTTP和URI。如果你在设计应用程序时能坚持REST原则，那就预示着你将会得到一个使用了优质Web架构（这将让你受益）的系统。总之，五条关键原则列举如下：
- 为所有“事物”定义ID （所谓的”事物“即就是”资源“）
- 将所有事物链接在一起
- 使用标准方法
- 资源多重表述
- 无状态通信
1）为所有的事物定义ID
在Web中，代表ID的统一概念是：URI。URI构成了一个全局命名空间，使用URI标识你的关键资源意味着它们获得了一个唯一、全局的ID。
第一个原则：使用URI标识所有值得标识的事物，特别是应用中提供的所有“高级”资源，无论这些资源代表单一数据项、数据项集合、虚拟亦或实际的对象还是计算结果等。
2) 将所有事物链接在一起
这个描述的核心是超媒体概念，换句话说：是链接的思想。链接是我们在HTML中常见的概念，但是它的用处绝不局限于此
使用URI表示链接的优雅之处在于，链接可以指向由不同应用、不同服务器甚至位于另一个大陆上的不同公司提供的资源——因为URI命名规范是全球标准，构成Web的所有资源都可以互联互通。
超媒体原则还有一个更重要的方面——应用“状态”。简而言之，实际上服务器端为客户端提供一组链接，使客户端能通过链接将应用从一个状态改变为另一个状态。记住：链接是构成动态应用的非常有效的方式。
对此原则总结如下：任何可能的情况下，使用链接指引可以被标识的事物（资源）。也正是超链接造就了现在的Web。
3)使用标准方法
除了两个大家熟知的（GET和POST）之外，标准方法集合中还包含PUT、DELETE、HEAD和OPTIONS
REST 要求开发人员显式地使用 HTTP 方法，并且使用方式与协议定义一致。 这个基本 REST 设计原则建立了创建、读取、更新和删除（create, read, update, and delete，CRUD）操作与 HTTP 方法之间的一对一映射。 根据此映射：
- 若要在服务器上创建资源，应该使用 POST 方法。
- 若要检索某个资源，应该使用 GET 方法。
- 若要更改资源状态或对其进行更新，应该使用 PUT 方法。
- 若要删除某个资源，应该使用 DELETE 方法。
HTTP Method 与 CURD 数据处理操作对应 | ||
HTTP方法 | 数据处理 | 说明 |
POST | Create | 新增一个没有id的资源 |
GET | Read | 取得一个资源 |
PUT | Update | 更新一个资源。或新增一个含 id 资源(如果 id 不存在) |
DELETE | Delete | 删除一个资源
|
每一个方法都有其特定的使用范围，因此应该正确的使用这几个方法（如更新数据，虽然使用GET，变相也能完成，但是还是应该使用PUT方法）
在基于 REST 的 Web 服务中，协议已经对动词（POST、GET、PUT 和 DELETE）进行了定义。 在理想的情况下，为了保持接口的通用化，并允许客户端明确它们调用的操作，Web 服务不应该定义更多的动词或远程过程
资源多重表述
针对不同的需求提供资源多重表述。
客户程序如何知道该怎样处理检索到的数据，比如作为GET或者POST请求的结果？原因是，HTTP采取的方式是允许数据处理和操作调用之间关系分离的。换句话说，如果客户程序知道如何处理一种特定的数据格式，那就可以与所有提供这种表述格式的资源交互。理想的情况下，资源表述应该采用标准格式——如果客户程序对HTTP应用协议和一组数据格式都有所“了解”，那么它 就可以用一种有意义的方式与世界上任意一个RESTful HTTP应用交互。不幸的是，我们不可能拿到所有东西的标准格式，但是，或许我们可以想到在公司或者一些合作伙伴中使用标准格式来营造一个小环境。当然以 上情况不仅适用于从服务器端到客户端的数据，反之既然——倘若从客户端传来的数据符合应用协议，那么服务器端就可以使用特定的格式处理数据，而不去关心客 户端的类型。
在实践中，资源多重表述还有着其它重要的好处：如果你为你的资源提供HTML和XML两种表述方式，那这些资源不仅可以被你的应用所用，还可以被任意标准Web浏览器所用——也就是说，你的应用信息可以被所有会使用Web的人获取到。
资源多重表述还有另外一种使用方式：你可以将应用的Web UI纳入到Web API中——毕竟，API的设计通常是由UI可以提供的功能驱动的，而UI也是通过API执行动作的。将这两个任务合二为一带来了令人惊讶的好处，这使得 使用者和调用程序都能得到更好的Web接口。
5）无状态通信
指的的是服务端不保存状态，将状态信息保存在客户端
