对于我目前项目中的 请求地址
/user/add 用户新增
/user/delete 用户删除
/user/pageQuery 用户列表拆线呢
/user/detail 用户详情
全是 post 请求，这种算是 Restful 风格嘛
我查了下相关介绍
GET /products : will return the list of all products
POST /products : will add a product to the collection
GET /products/4 : will retrieve product #4
PATCH/PUT /products/4 : will update product #4
大概是请求地址相同 然后是根据 GET POST PUT 这种做交互的才是 Restful 么
不是你用上了 PUT PATCH 就是 RESTful，而是你使用资源的抽象方式的接口风格概括。建议可以学习一下 GitHub API v3 。
GET /users 获取所有用户列表
GET /users/1 获取单个用户详情
POST /users 新增用户
PUT /users/1 修改用户
DELETE /users/1 删除用户
这样才是 RESTful
你能分得清这俩 API 的区别么
比如 /users 这个路径代表的就是对 user 资源的访问，采用 get 请求就是获取用户信息，采用 post 请求就是新增。
两两对比着看下面的例子。
GET /users 获取所有用户列表
POST /users 新增用户
GET /users/1 获取 id 为 1 用户
PUT/users/1 修改 id 为 1 用户信息
包括外面的壳在内..服务端的代码和设计都是适合 restful 方式的才算 restful
比如你可以参考 openstack 的 neutron,这个项目的就是完完全全的 restful
但是 openstack 的 nova 就不是 restful
一个原因是 nova 比较早,当时没有按照 restful 的方式设计,还有一个问题是 nova 的 api 不是那么适合完全用 restful 表达
如果你的业务适合用 restful 表达..那么对外接口和代码设计上可以有很强的一致性
否则,不应该被规范束缚,就像不应该完完全全用范式来束缚数据库设计一样
其实之前论坛里有个人非常精准的形容了 restful——对 sql 的劣质模仿
“你这 url 一点也不 restful，对不起我们不是一类人，我们追求不一样”。
上述言论多见于一些毕业不过一两年的人。
回主，我的感觉 restful 就是从面向过程编程跃迁到面向对象编程。不是所有接口都能 restful，看着来吧。
用 GET 的很多缺点
1. 缓存。GET 请求在浏览器和运营商层面都会认为是不变的，那么是可以被缓存的，但是如果你修改了某个实体后，再 GET 这个实体，怎么保证能拿到的是新的？也可能你自己设置了合理的缓存时间，但是会被某些无良运营商缓存。这个要么就是加一个 `t=timestamp` 的随机串在后面避免缓存，但这样 GET 的意义是啥
2. 无状态。按 Restful 的定义，GET 是无状态和幂等的，但是有些 GET 就是会影响其他数据，比如微博的阅读量被拿一次就应该加一，比如某些已读状态的标记，是从 GET 请求算，还是 GET 后客户端再 POST 或 PUT 一个请求来更新？只用 GET 就违反了无状态和幂等的原则
3. 请求体大小。这个是早期浏览器的限制，GET 请求的请求参数不能超过 1024 个字节，如果遇上复杂一点的请求结构就挂了，还是只能走 POST
比如
要获取所有用户列表：GET /users
获取用户 a 的信息 GET /users/a
新建用户 POST /users
更新用户 a 的信息 PUT /users/a
删除用户 a DELETE /users/a
GET 查询数据，只读请求，支持幂等调用，对数据不产生任何影响
POST 修改数据，增删改请求，对数据产生影响
没有完全按照 RESTful 的规范来，但用请求 METHOD 区分一下，还是非常有必要的。
这些是介于面向资源库和面向实体之间的操作，对资源库来说是修改指定实体，对实体来说是“维修”行为：
PUT /users/{id} “整体换新”
PATCH /users/{id} “换零件”
前面的这些，基本上是通的。即使不是信息系统或者不使用领域模型，例如内容管理系统，当然最典型的还是万维网（ www ）资源体系，都是这样用（但是不同的背景有不同的具体含义）。而下面这些，则是领域模型专用的，并且是最主要的。他们面向实体，表示实体的一个行为：
POST /users/{id}/eat
POST /users/{id}/drink
POST /users/{id}/shit
POST /users/{id}/xuxu
POST /users/{id}/sleep
POST /users/{id}/… …
必须纠正一个误区，RESTful 不禁止动词。对于万唯网资源和内容管理系统来说，他们是只对资源做操作从而不会有动词，并不是禁止动词。而信息系统，不只是管理资源，还要支撑业务，是要用到动词的。
手机敲字真累
POST /products.retrieve : will return the list of all products
POST /products.add : will add a product to the collection
POST /products/4.retrieve : will retrieve product #4
POST /products/4.update: will update product #4
只不过这种私有私有约定并不友好。
一个简单的判定是不是 RESTful 的方法就是，去掉了动词之后，剩下的 url 是不是你们业务中的一种资源的抽象。你的项目中的例子明显就违背了这一点。
/user/pageQuery 用户列表拆线呢
/user/detail 用户详情
去掉了动词之后，都是 /user/，但他们明显不是一个东西。
@Renco
@WittBulter 其实自己的 REST API 质量很容易判断，可以自行搜索 Richardson Mature Model （网上介绍太多了），这是一个公认的判断 REST 质量的检测规则。自己比较一下自已设计的 API 到了哪个 Level，Level 2 以下的基本不叫 REST，Level 3 描述的 Self-documentation 特性是比较理想的状态（无需文档基础上可以清楚整个 API 的 schema 的树形结构），实际国外很多公开 API 都做到了（ Github，Heroku 等）。国内大厂很多都是在 Level0，或者 Level1，V 站很多人在谈技术的时候往往不讨论技术本身，而是迷信某些大厂怎么做的，所以我一直觉得某些大厂把国内技术带歪了。
另外， 国外已经有相当一部分 API 开始提供 GraphQL，GraphQL 违反 REST 一些设计规则，但是很好的解决 REST 在交换数据上颗粒度的问题。
想一下你浏览 V2EX 的这个过程：你在浏览器输入 v2ex.com 或者从别的网站跳过来。服务器向你发送超媒体文本标记语言（也就是 html ），浏览器渲染后你可以看到这个帖子的链接，于是你知道你可以点这个链接从而看到这个帖子。作为人类你是自我驱动地去看到各种各样的超媒体（图片，链接，表单等等）并去获取各种各样你所要的信息。
理想情况下的 restful 是这样子：你的客户端向 v2ex.com 请求（协议和方法不限），服务器响应的也是一个超媒体，包括一些信息和客户端接下来可以进行的行为。在“人类”的例子里就是 html 和<a>。你的客户端想要看关于 restful 的信息所以它请求了这个帖子的接口，从而获取到了信息。
http 和 http 的方法只是方便了机器之间约定了请求的方法。但是 restful 可以不依赖于具体的网络协议和方法。如果服务器和客户端之间的交流是基于超媒体的，那么即便你全用 post 和 200 也可以是 restful api 。
select * from users
insert into users values(…users)
select * from users where id = 1 limit 1
update users set name = name where id = 1
delete users where id = 1
进阶：
获取用户的收藏
/users/:user_id/coll
user = select * from users where id = 1 limit 1
coll = select * from coll where user_id = user.id