我是一个人么,还有人觉得 RESTful 是糟糕的设计么。

2014-05-09 14:54:45 +08:00
 jybox
我主要写后端代码,以前写 PHP, 现在写 Node.js. 刚听说 RESTful 的时候,觉得很高端大气上档次,很理想很美好。但在后来的实践中发现 RESTful 很大程度上拖慢了后端的开发速度,而对前端(AngularJS)的开发速度改善也很有限。

RESTful 希望将所有请求都包装成对资源的新增,读取,修改,以对应不同的 HTTP 动词,但是并非所有请求都可以归到前面几类,既然无法将所有请求都 RESTful 化,甚至无法将大部分的请求 RESTful 化,那么意义就很有限了,会导致花费大量时间斟酌 API 应该如何设计。

RESTful 将一部分参数放到了 URL 里,还有一部分参数在 Header 里,从 URL 和 Header 里分离参数,虽然有库的辅助,但是我觉得很麻烦。

RESTful 通过 Status Code 来表示结果状态,但是通常的情况下,结果只有成功和出错两种情况,出错的情况分很多种,原因都很复杂,即使有 Status Code 依然需要有一个字符串来描述错误详情,所以 Status Code 在这里就显得很多余了。

所以我现在开始坚定地黑 RESTful, 我认为「传统」的 API 设计才是最可行的,即:

* URL 是一个动词,其中不包含参数。
* 没有副作用的请求可以用 GET, 其余必须 POST
* POST 时用正文传递参数,GET 时用 Query String 传递参数
* Status Code 为 200 或 400, 后者会返回一个字符串形式的错误代号。
13100 次点击
所在节点    程序员
39 条回复
robertlyc
2014-05-09 15:00:40 +08:00
先把Roy Fielding的博士论文读懂
ddyy
2014-05-09 15:03:18 +08:00
同样的道理也可以用在“面向对象”、“设计模式”、“TDD开发”上,理想很美好,但现实需求很凌乱,让这些看上去很美的“模式”套不上
hepin1989
2014-05-09 15:06:32 +08:00
怎么容易怎么弄,爱咋地咋地
robertlyc
2014-05-09 15:17:53 +08:00
难怪 原来是php程序员
binux
2014-05-09 15:20:01 +08:00
- RESTful 是一种思想,但它没有规定所有的事情,一只装备了 RESTful 的猴子并不能设计 API
- 参数在URL中和在 header 中的语意是不一样的,对应后端的处理路径也不一样,这样拆分是有意义的
- status code 是对出错类型的分类简化,用户可以在不知道具体出错原因的情况下,根据类型采取不同的动作,例如对于 400 是客户的错,500 的原因是服务器的问题,并进行重试。status code 的错误归纳是标准化非常有价值的设计。
cloudzhou
2014-05-09 15:38:34 +08:00
一一回应:
1 get, post, put, delete 方法的细化,可以很容易在上层做权限拦截,从读取,新建,修改,删除层次上就做到了,当然这个是对方法的使用比较严格。
对于一般的资源,比如 /v1/user/1/ (几个方法表示获取,创建,修改,删除),如果用你现在的方法,那要怎么表示,无论如何都会很冗余。
rest 是为了描述通用资源的管理,如果你抽象得好,绝大多数请求都是可以归类出来的。其他的你可以自行实现,比如你说的「传统」的 API 设计...
2 从 URL 和 Header 里分离参数是有特别意义的,比如 https://developer.github.com/v3/#authentication,用户认证的 Token 必须放到 Header,如果你放在 URL 里,这是一种不安全的方法。总之,敏感信息是不能带在 URL 上面的,类似 Token,sessionid,Header 是最好的选择。
3 Status Code的细分,你看看下面的描述,你觉得这些没有用的?
200: 正常,可能附带数据
201: 需要创建的对象已经存在
400: 请求参数或者格式不对
403: 没有相关的权限
404: 资源没有找到
500: 内部数据出现错误

总结:
大部分的麻烦,要考虑是不是代码写得不对,因为 rest 的这种规范,代码其实更好写的,以 java 为例子,非常好做继承和复用,统一的错误和异常处理,比如一旦 403 转到权限不足提示页面。
unstop
2014-05-09 15:47:48 +08:00
@binux @cloudzhou 感谢二位的答案,很有帮助!
iwege
2014-05-09 16:15:44 +08:00
> "但在后来的实践中发现 RESTful 很大程度上拖慢了后端的开发速度,而对前端(AngularJS)的开发速度改善也很有限。"

主要的原因是你没用framework... nodejs是因为express本身非常轻量级所以很多需要自己配置。换做Laravel,CakePHP或者ROR,开发速度是杠杠的..


> "甚至无法将大部分的请求 RESTful 化,那么意义就很有限了,会导致花费大量时间斟酌 API 应该如何设计。"

1. 你尚未真正明白RESTful的意义。
2. API的设计是很花费时间的,除非直接抄,否则推到两三次都是正常的。如果不需要设计API还不如直接后端render好了.
3. 如果你觉得RESTful不够好,你可以考虑SOAP

“所以我现在开始坚定地黑 RESTful”

一般来说,坚定的黑你就要一直不使用他的理念:
http://www.infoq.com/cn/articles/understanding-restful-style

以上文章里面提到的你要坚决的一点都不用的话,应该才算是坚定的黑.

PS. 翻了楼主的帖子发现《王垠又接着写博客了》的那张贴,顿时明白了前辈们的智慧是如此的闪耀...
learnshare
2014-05-09 16:19:01 +08:00
@cloudzhou +10086

1. RESTful 是为了将数据/资源抽象化,形成统一的方法(GET/PUT/PUST/DELETE),方便前(or 客户端)后端进行 API 的规范化。
2. header/params/data 的功能不同,这个应该是属于 HTTP 协议部分吧,我不是很了解。
3. 状态码是一种规范,或者叫标准。现在应该大部分人都知道 404 了,这就是标准带来的好处。

如果你的程序没有达到一定规模,使用 RESTful 可能真的是多余。

如果你的程序需要(或者将来可能需要):
1. 稳定健壮可扩展;
2. 支持不同终端/客户端访问(Web、App 或 其他程序调用);
3. 有其他人来接手/参与...

建议使用 RESTful
airyland
2014-05-09 16:22:58 +08:00
虽然楼主觉得理解透了而且也实践了,但是还是建议再去看看别人的设计别人的实现 。
“拖慢开发速度“这不是RESTful的问题,是你们开发上的问题。
learnshare
2014-05-09 16:27:51 +08:00
@unstop
>如果不需要设计API还不如直接后端render好了.

我司的另一个技术领导一直坚持后端 render,其实也未尝不可。

具体采用什么,还要看自己是不是熟悉。不过在深入了解一门技术之前,先别 **扣帽子** 。
lyd600lty
2014-05-09 16:28:04 +08:00
满足需求,开发顺畅,用不用RESTFUL都可以啊。
bolasblack
2014-05-09 16:37:24 +08:00
@lyd600lty 确实用不用都可以,只是如果接受这个风格的话,那么其实是能够提升开发效率的。就像 @lwege 说的一样,你发现突然出现了很多工具来帮助你完成你的工作,而且你也能找到很多的实践和方法来解决你遇到的问题
learnshare
2014-05-09 16:38:48 +08:00
#11 at 错了,sorry :)
binux
2014-05-09 16:38:53 +08:00
@lyd600lty 当你要和别人解释你的 API 的时候,RESTful 会帮你省去很多口水
lyd600lty
2014-05-09 16:41:08 +08:00
@binux 确实是这样,不过我曾经跟楼主纠结这个问题的时候,我也费了很多口水- - ~
soli
2014-05-09 16:54:32 +08:00
HTTP status ranges in a nutshell:

1xx: hold on
2xx: here you go
3xx: go away
4xx: you fu*ked up
5xx: I fu*ked up
justfindu
2014-05-09 16:58:24 +08:00
@robertlyc 能别黑php程序员么 碍着你了么~ 只有你用的语言才是高大上,好又多么~
alsotang
2014-05-09 16:59:47 +08:00
restful 跟 sql 的 crud 配合得很好。
楼主什么场景?
mfaner
2014-05-09 17:41:57 +08:00
REST才是HTTP的本意。
用过WebDAV没?你会发现HTTP是多赞的协议。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/111775

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX