RESTful网上有很多解释，现在看来其实挺简单的。它本身就是一种风格，不遵守也没啥，但这么多人都愿意遵守这种风格。也是自然有其原有的。
1.非RESTful实例和RESTful风格的写法对比
比如我们在没有遵守RESTful风格前，按照我的习惯要写一个员工的增删查改大概会这样写：
http://localhost:8080/employee/get/{id} GET
http://localhost:8080/employee/delete/{id} POST/GET
http://localhost:8080/employee/create POST
http://localhost:8080/empliyee/update POST
基于RESTful风格的写法我大概会这样：
http://localhost:8080/employee/{id} GET
http://localhost:8080/employee DELETE
http://localhost:8080/employee POST
http://localhost:8080/empliyee PUT
如果遵循现在更细的写法可能还会多一种（不细分可归属到PUT下，其实这样说不对的幂等性不一样）
http://localhost:8080/empliyee/salt PATCH
首先，风格这玩意不好去硬性要求，但大神们都这么玩。就我目前使用而言，没有使用RESTful风格前，请求路径中需要很多的动词和名称结合着去描述这个请求的具体行为。RESTful则不需要这些动词描述，只需要名词，和规定的请求方式来描述，最直观的表现就是url短了，当然好处应该不止如此，其实就是整体一致性，更少的描述词汇，更准确的直观快速的描述，这点对我而言是在面对一堆自由风格的个性请求时才真的有体会到的。
2.GET|DELETE|POST|PUT|PATCH的使用
关于他们的使用，首先要说一个点，就是操作的影响，网上也有说对资源的操作等专业的说法。我理解就是真正的影响，影响可以用数据库相关的概念来类比，如增删改查。
查 影响：土一点说除了让你看到啥影响也没有，查一万次也是如此。
增 影响：确实是多了一条数据或者多条数据，原来没有，从无到有。即使数据库有唯一校验，相同手机号的人，不可能再被创建，但从影响上来说，他是确确实实是增。
改 影响：原来就有，但是对原有的景象修改。（细分可分为改具体的，或者整个对象，比如改一个员工全部的属性，或者只改密码的接口）
删 影响：删除原来就有的，如果软删其实改，但是前端真的看不到了，也可放到删里。
| 请求方式 | 幂等 | 安全 | 操作 |
|---|---|---|---|
| GET | 是 | 是 | 查 |
| POST | 否 | 否 | 增 |
| DELETE | 是 | 否 | 删 |
| PUT | 是 | 否 | 改 |
幂等：可以理解执行一次和多次影响和第一次一样的。
安全：是否改变了数据，没改变数据就是安全的。
解释起来是这样的，修改一个员工的密码的接口。他是操作里的改操作，这个操作执行n次的结果都是一样的。当然这个用PUT是完全可以的，如果确实能描述的清楚，是局部的修改，PATCH更为准确。虽然我目前没怎么用，但是解释起来是合理可行的。所以，大环境使用的话，PATCH也还是可以很快适应的。
PS：我对于RESTful的理解目前是这样的，大多也是看帖子，加自己项目中实践意淫出来的。想一想觉得能解释的通，就认为自己差不多是理解对了。所以有错误的地方，欢迎批评指正。
