看了一堆的 Restful 的介绍 还是没太理解

[Renco]

对于我目前项目中的 请求地址

/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 么

[WittBulter]

1. 不算。
2. 请求地址相同也不能严格的算 RESTful 。接口的方式变化只是操作资源的表达方式，并非是对 RESTful 的判断依据。

不是你用上了 PUT PATCH 就是 RESTful，而是你使用资源的抽象方式的接口风格概括。建议可以学习一下 GitHub API v3 。

[Mithril]

你这个显然不是。
你说的请求地址在 RESTful 里面代表某种资源，通过不同的 HTTP 方法来表示对资源的操作。
不过在实际项目里面并不会完全按照 RESTful 来设计全部 API 。总会在 RESTful API 和瞎胡搞 API 之间取得一个平衡。主要是全部用 RESTful 来做的话，有些逻辑就会变得很奇怪，而且很难设计。

[godgrp]

不是单纯的请求地址相同哦，而是把请求的目标看作是一个资源，使一个请求更语意化。建议地址上尽量不出现动词，动作由 Http Method 来表达。当然这是一个理想化的约定，因为仅仅是个约定或者是规范，并不是一个协议，没有强制约束的。

[fengerzh]

不是。改成：

GET /users 获取所有用户列表
GET /users/1 获取单个用户详情
POST /users 新增用户
PUT /users/1 修改用户
DELETE /users/1 删除用户

这样才是 RESTful

[ericgui]

GET /users 获取所有用户列表
POST /users 新增用户

你能分得清这俩 API 的区别么

[kiracyan]

感觉 RESTful 适合对外公用接口，让 API 调用者更方便使用，内部 API 感觉完全按照 RESTful 风格，有些接口会变得很奇怪，有完整的使用 API 文档是不是 RESTful 感觉应该没什么太大差别

[useben]

@ericgui 所以是动作操作是通过请求方法来判断, url 只是表示资源

[EastLord]

还有接口的返回格式

[strawberryBug]

简单理解，REST 是一种理想化的约定，规范，实际设计 api 可以不按照这个来。REST 里 URL 路径代表对具体资源的访问，http 请求的方式代表对该资源的操作。

比如 /users 这个路径代表的就是对 user 资源的访问，采用 get 请求就是获取用户信息，采用 post 请求就是新增。

两两对比着看下面的例子。
GET /users 获取所有用户列表
POST /users 新增用户

GET /users/1 获取 id 为 1 用户
PUT/users/1 修改 id 为 1 用户信息

[taaaang]

restful 还有个意思就是尽可能规范得设计 url, 使用 http 协议。

[VDimos]

post 和 get 一把梭

[noobsheldon]

wonderful, beautiful, restful

[lolizeppelin]

对外 url 表现,只是壳,所以你不理解

包括外面的壳在内..服务端的代码和设计都是适合 restful 方式的才算 restful

比如你可以参考 openstack 的 neutron,这个项目的就是完完全全的 restful
但是 openstack 的 nova 就不是 restful

一个原因是 nova 比较早,当时没有按照 restful 的方式设计,还有一个问题是 nova 的 api 不是那么适合完全用 restful 表达


如果你的业务适合用 restful 表达..那么对外接口和代码设计上可以有很强的一致性
否则,不应该被规范束缚,就像不应该完完全全用范式来束缚数据库设计一样


其实之前论坛里有个人非常精准的形容了 restful——对 sql 的劣质模仿

[SpencerCJH]

你看看这个 https://cloud.google.com/apis/design

[namelosw]

1 不算，2 可以算 REST，但是这个是简单情况，后面有很多很难判断的，要把各种动作建模成资源。
比如登陆不叫登陆叫 POST /sessions
REST 看个基本就可以了，不用太纠结，很多东西用 REST 没法建模，比如搜索之类的。

[murmur]

实际开发中严格的 restful 反倒是撕逼的根源，大家的所谓 restful 都是留了后手的

[fkdog]

一个资源设计风格而已。
v2 上有的是这类把 restful 当成圣经一样跪拜的人。

“你这 url 一点也不 restful，对不起我们不是一类人，我们追求不一样”。
上述言论多见于一些毕业不过一两年的人。

[lookas2001]

@fkdog 我看了半天楼上的回复没看到你说的那一类人啊。

回楼主，我的感觉 restful 就是从面向过程编程跃迁到面向对象编程。不是所有接口都能 restful，看着来吧。

[whusnoopy]

在项目里尝试过，在 HTTP 时代被宽带运营商强 * 得不能自理，最后还是自己定义接口路径，并且全走 POST

用 GET 的很多缺点

1. 缓存。GET 请求在浏览器和运营商层面都会认为是不变的，那么是可以被缓存的，但是如果你修改了某个实体后，再 GET 这个实体，怎么保证能拿到的是新的？也可能你自己设置了合理的缓存时间，但是会被某些无良运营商缓存。这个要么就是加一个 `t=timestamp` 的随机串在后面避免缓存，但这样 GET 的意义是啥
2. 无状态。按 Restful 的定义，GET 是无状态和幂等的，但是有些 GET 就是会影响其他数据，比如微博的阅读量被拿一次就应该加一，比如某些已读状态的标记，是从 GET 请求算，还是 GET 后客户端再 POST 或 PUT 一个请求来更新？只用 GET 就违反了无状态和幂等的原则
3. 请求体大小。这个是早期浏览器的限制，GET 请求的请求参数不能超过 1024 个字节，如果遇上复杂一点的请求结构就挂了，还是只能走 POST

[Flywith24]

貌似 RESTful 没有 明确的定义？我的理解就是正确地使用 http