1、面向资源：
每个资源都有专人负责，我们可以直接面向资源操作。
/orders
{
"addOrder": {
"orderName": "H&M"
}
}
斜杠和orders表示我们这个请求是发给哪个资源的，订单是一种资源，我们可以理解为是衣服制作工厂专门管理订单的人，他可以帮我们处理所有有关订单的操作，包括新增订单、修改订单、取消订单等操作
注：面向资源，对构建可伸缩、分布式的架构至关重要的。同时，如果面向资源使用的数据格式是Xml，那么其实就是SOAP，SOAP的特点是关注行为和处理，和面向资源的RESTful有很大的不同。
2、给请求打上标签
新增资源的请求，都在请求上面写上大大的‘POST’，表示这是一笔新增资源的请求
查询类的请求，用‘GET’表示
删除类的请求，用‘DELETE’表示”
修改类的请求，修改分为两种：
第一种，如果这个修改，无论发送多少次，最后一次修改后的资源，总是和第一次修改后的一样，比如更改订单的衣服的款式，那么用‘PUT’表示
第二种，如果这个修改，每次修改都会让这个资源和前一次的不一样，比如是订单中加一件衣服，那么这种请求用‘PATCH’或者‘POST’表示
以上使用了HTTP动词，GET/PUT/POST/DELETE/PATCH....,这些都是HTTP的规范，规范的作用自然是重大的，用户看到一个POST请求，就知道它不是幂等的，使用时要小心，看到PUT，就知道他是幂等的，多调用几次都不会造成问题
3、在请求中同时返回所有可以对此所做的操作及如何操作，比如告诉请求者如何删除订单
在请求中返回可以做哪些操作，这种操作叫HATEOAS（Hypertext As The Engine Of Application State），中文翻译为“将超媒体格式作为应用状态的引擎”，核心思想就是每个资源都有它的状态，不同状态下，可对它进行的操作不一样。理解了这一层，REST的全称，Representational State Transfer，中文“表述性状态转移”就容易理解多了。
这种设计的Restful API，给使用者带来很大的便利：
使用者只需要知道如何获取资源的入口，之后的每个URI都可以通过请求获得，无法获得就说明无法执行那个请求。
做到了面向资源和使用Http动词，就已经很Restful了。Restful本身也不是一种规范，Restful风格来称呼更合适一些。
