V2EX 首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐书目
黑客与画家
REWORK 简体中文版
REWORK 精装原版
深入浅出设计模式 Head First Design Patterns
代码之美 Beautiful Code
数据之美 Beautiful Data
信息论、编码与密码学
Free as in Freedom
设计原本
精通正则表达式
V2EX  ›  程序员

RESTful 有用吗? HTTP 有 GET POST 就足够了?

  •  
  •   noli · 5 天前 · 9416 次点击

    不少程序员都是这么认为的,基于 HTTP API 的服务,只要用 GET 请求和 POST 请求就足够了。 像 RESTful 这样的 大量使用 PUT , DELETE 请求是不必要的。

    真的吗,我来举一个例子。

    假设有一类资源 ResourceXYZ ,对其有增删查改的操作。 如果只使用 GET POST 之类的设计方式,那么很可能会设计以下的请求接口:

    POST .../addResourceXYZ
    POST .../delResourceXYZ
    GET .../getResourceXYZ?resourceId=resourceId
    POST .../updateResourceXYZ
    

    如果按照 RESTful 的 设计方式,很可能会设计以下的请求接口

    POST .../ResourceXYZs
    DELETE .../ResourceXYZ/{resourceId}
    GET .../ResourceXYZ/{resourceId}
    PUT .../ResourceXYZ/{resourceId}
    

    现在假设,客户端要获取该资源,其 ID 为 resourceId 。 如果成功,那么一切都好说。 如果失败, Restful 的处理方式是,通过 HTTP status 返回错误码来表示原因,例如 404 表示该资源不存在。

    那么只用 GET POST 两种方法的方式呢? 响应请求

    GET .../getResourceXYZ?resourceId=resourceId
    

    的时候能不能也用 404 呢?

    按照 404 的语义,响应 404 是不对的: 因为客户端请求的 URL 实际上是正确的,只是对应的参数没有找到对应的结果 很多时候,就只能靠响应 200 然后返回空数据或者空对象来处理了。 例如 Content-type 为 application/json 时,可以返回 {} 或者

    {
        "error": "not found",
        "code": 404
    }
    

    这样就会要求客户端,必须处理 HTTP 回复的具体内容,而不能只处理头部。 那么客户端要怎么处理这个 json 呢 要先解析 json ,然后尝试分别这是一个资源的内容,还是一个错误提示。

    对于强类型语言例如 C/C++ OC Swift 写的客户端来说,恐怕就忍不住要问候服务端程序员一家了。

    更重要的是……

    没有库会支持这种拍脑袋式的设计。

    全文完,欢迎拍砖。

    173 回复  |  直到 2017-02-19 02:17:31 +08:00
    1  2  
        101
    wizardforcel   3 天前
    @noli

    > 至于为什么 HTTP API 调用 HTTP API ,那是因为 do not repeat your self. 当这些被调用的 更底层 API 实现有变动的时候,你不需要改高层 API 的实现,虽然这也不一定是必须的。

    HTTP API 的粒度太大,资源开销也大,服务端自己复用自己的时候,一般采用 DAO 的形式。看样子你根本不懂后端,就是一个架构太空人而已。
        102
    noli   3 天前 via iPhone   ♥ 1
    @wizardforcel

    天真。你以为 任何层的服务器应用都能调用 DAO 访问数据库吗?看样子你根本没做过严格的系统,都是搞些什么 login reg 之类的小社区吧
        103
    cnt2ex   3 天前
    顺便说一句, C/C++是弱类型
        104
    wizardforcel   3 天前
    @noli

    99% 的 Web 系统都是这样做的。至于那 1%,你说这么大堆就是为了证明 REST 只是为极端情况下服务的? REST 真牛逼,呵呵,但是跟我没关系,我是这 99%。
        105
    noli   3 天前 via iPhone
    @wizardforcel

    你说 99%的都是那么做我是信的,因为 99% 的公司都没有机会有上每天百万级别的 api 调用次数,要协调近百人的 team 来维持 api 服务。

    算啦,知道你不服气。正面回应你吧。

    你一直在说 http api 调度代价大,事实上数据库访问的代价更大,连接数基本上都是有上限限制的。数据库的调用逻辑更是测了又测。我扩张几台几十台 http server 简直是简单得不要不要的。再况且,我们这里背后的数据库是 mysql 代理,并不是什么 feature 都能支持,你随随便便搞个 DAO 还真不能保证 100%能用。

    要是你选你也会选我一样的做法。
        106
    noli   3 天前
    @cnt2ex

    你说得对, C/C++ 自身不是强类型的。但实际开发中我们很喜欢用它们的强类型特性。
    所以不妨视作强类型的吧?
        107
    Mitt   3 天前
    服务器代价不代价的 能不能支撑几百万访问的 跟这个问题一点都没有关系吧 这种问题丢给架构师啊, REST 确实对于某些资源性特别强的时候要比只有 GET,POST 好用,但是很少啊,第一眼看上去什么都是资源,但是后期如果要对这个资源操作其他的事情,你就只能去改,把 REST 再改回 API ,你改了还不要紧,用你接口的也要改,还不如一开始就设计一套有风格又优雅的 API 接口,具备扩展性和优雅,还可以自己维护一套返回值类型,不必过度拘束 HTTP 的返回值,你说你如果又有 REST 又有 API 的话 客户端还得针对 REST 和 API 分别维护两套处理流程,何必呢?
        108
    noli   3 天前
    @Mitt

    如果你的 API 使用者都是自己公司的,你这么做当然很 OK ,怎么任性也不会直接扣你钱。

    但是重构这种事情,不是 RESTful 就有其他 API 就没有的。 而 RESTful 可以有版本,甚至你还可以给资源起一个新名字,然后将请求 forward 过去。善用 URL 就是有这么大的好处。

    你自己设计一套 API 接口,要么按这个套路,要么不兼容以前的调用。
    如果 API 里面没有 URL 没有版本这个概念,升级就够你烦的了。
    那说来说去,还是说明 RESTful 的已经想得够多了,不像很多人以为的那么肤浅。
        109
    Mitt   3 天前
    @noli 其实你说的那些 REST 的好处 都是后端框架可以实现的 并不是指就非要以 REST 才有这种特性
        110
    Mitt   3 天前
    @noli 总的来说 纠结半天的 REST 和 API 的区别就是 请求格式和返回格式 两者, 而这完全看团队风格或者个人风格了, 所以不要在这上面总是纠结谁好谁坏了,这两个都是平等的,完全可以自己设计一套适合自己的 "RESTful"
        111
    noli   3 天前
    @Mitt

    请你明确指出我说了哪些 RESTful 的好处,然后也符合你说的后端框架也可以实现的。

    不过,退一万步来说。
    RESTful 肯定不是蝎子拉屎独一份,但它是一个基于 RFC 的、有多种开源实现的规范。
    我从来不反对谁谁用自己定制的协议和框架,
    我只是讨厌那些对 RESTful 一知半解对 RESTful 的风格选择性遵守然后又把脏水倒到 RESTful 身上。

    我想强调的是,如果你想清楚了,你怎么设计都可以。
    如果你没有想清楚 ,多参考 RESTful 的设计以及这个设计是解决了哪些问题(很多人就是不理解 这些设计就来吐槽)
    最后,如果你很懒,不想想那么多,那么直接按照 RESTful 规范来做,就是最省事的(很多人就是做到一半以为自己比 RESTful 高明又玩自己的一套)

    这些人里面,国内程序员尤为严重,什么反范式啊反权威这样的话都说出来了。
    好像他们自己的不幸就是他们口中的这些范式啊权威啊导致似的。
        112
    danielmiao   3 天前   ♥ 2
    个人觉得, Restful 只是一个参考而已。。实际应用中还有很多问题,前后端调用只是一部分,涉及到微服务调用上情况会更复杂,举个 404 异常例子:
    前后端分离情况:足够描述资源找不到的问题,对用户来说不管什么问题,都是没找到资源而已。
    微服务架构:完全不够,造成 404 的问题,有可能是没有部署这个接口,也可能是负载均衡有问题,也可能是真的没这个资源,还有可能是参数组合有问题(也可以用 400 描述,但是 400 情况同样,具体不到哪个参数有问题)。
    所以说, restful 只是一个风格而已,未必要完全一样,在 RPC 里很容易解决的问题,在 http 上可能有很多问题,不管是 ice , thrift , dubbo 可以定义大量的异常,同时不需要修改数据结构,但是到 http/restful ,没有异常这个概念,是需要定义量的错误码,还是复用原有的 http status ,我个人觉得还是自定义统一的错误体系会更好
        113
    noli   3 天前
    @danielmiao

    首先,如果是负载均衡有问题,你们确定是返回 404 吗?
    按我的经验,如果负载均衡是 Nginx 做的话,应该会是 503 或者 504 , 明确指出了这是服务端的问题。
    如果是客户端方面得到了错的 URL 那么 就是 4XX 可能是 404 也可能是 405.
    HTTP 的状态码本身就明确区分了责任方。

    第二, RESTful 并不拒绝自定义错误码,只是必须要与 HTTP 状态码意义不冲突
    事实上 AWS GCE 的 RESTful API 文档里面也定义了大量的自定义错误码。
    习惯的做法是用 Json Envelope ,将适用的真正要返回的数据封装在一个公共知晓的结构里面。
    怎么可以说 RESTful 没有异常的概念呢?

    请确定你有了解清楚 RESTful 的内容,例如本贴中 #39 给出了一个不错的参考来源,其中就有提到:
    “ Don't use an envelope by default, but make it possible when needed ”

    这怎么能说它不支持异常呢?
    讲道理的话, 3XX , 4XX 5XX 都能算作是异常。
        114
    danielmiao   3 天前   ♥ 3
    @noli
    我说的负载的问题是,如果你用 nginx 的时候,如果 ng 配置有误,会返回 404 。

    如果是服务调用方的失误(写错接口,复数多 s 少 s 很正常)或者服务提供方修改了接口定义(实际遇到过,手误在写接口名时,敲 ctrl+s 未成功,直接写出一个 s 而不自知,单元测试不通过 http 调用,未测出来)出现 404 是没有办法和业务状态的 404 所区分,特别是服务更新或者出现问题,很难定位是部署出现问题还是业务本身问题,运维和开发如果分离的情况更复杂。

    如果使用 json envelop 的话,实际上就是自定义错误体系,区分了 http 状态和业务状态。

    宽泛的说错误码和异常的作用可以等同,但是上文特指 Exception ,请勿偷换概念
        115
    noli   3 天前   ♥ 1
    @danielmiao

    这种 NG 配置错误的问题,要影响服务 API 设计工作吗?很难发现或者测出来吗?
    单元测试 RESTful 接口不通过 HTTP 调用……请问你们是怎么测?
    如果上司让你们因为这些低级错误改设计的话那你换公司好了。

    我再重申一下观点, RESTful 是工作在 HTTP 之上的,而且是与业务具体相关的协议
    所以肯定是有 HTTP 状态和业务状态两个概念。
    当然错误码也会有 HTTP 错误码 和 业务专有错误码,
    HTTP 错误码是为工作在 HTTP 层的各路非业务设备看的
    业务专有错误码是工作在业务端的,两者只要不含有意义冲突的定义。

    转帖一下大厂怎么设计 RESTful 错误码

    http://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
    https://developers.google.com/drive/v3/web/handle-errors
        116
    noli   3 天前   ♥ 1
    @danielmiao

    你的回复居然获得了一个赞,我很嫉妒,所以我再提供多一个简单的测试方法好了。
    如果你想知道 404 是谁搞出来的。
    curl -i 就可以看到是哪个服务器发出来的响应了。
    真心不理解为什么会难测难发现。
        117
    cxe2v   3 天前   ♥ 1
    @noli 那一个赞是我给的,你给出的两个大厂的例子明明就是自定义错误体系,怎么就变成了你宣扬的通过 HTTP STATUS CODE 来定义错误了,你不要偷换概念好嘛
        118
    noli   3 天前
    @cxe2v

    请问我偷换了什么概念?


    这是 AWS 的:

    REST Error Responses

    When there is an error, the header information contains:

    * Content-Type: application/xml
    * An appropriate 3xx, 4xx, or 5xx HTTP status code

    The body or the response also contains information about the error. The following sample error response shows the structure of response elements common to all REST error responses.


    这是 google 的:


    The Drive API returns two levels of error information:

    HTTP error codes and messages in the header
    A JSON object in the response body with additional details that can help you determine how to handle the error.
    The rest of this page provides a reference of Drive errors, with some guidance on how to handle them in your app.


    难道我在 #115 表达的不是这个意思?
        119
    noli   3 天前
    @cxe2v 知道你是这种水平之后,我也不稀罕你的赞了。
        120
    cxe2v   3 天前
    @noli 嗨呀,我难得认真一次,下面的回答我从第一页看过来的,你自己回去看看你 50 楼以前的回复怎么说的

    还有,你在 RESTful 规范不适合的时候强行用,借用其他“奇怪的技巧”?,我不得不说你这个 RESTful 不怎么 RESTful 啊
    我水平太次,你技术大牛,你去安利你的 RESTful 风格吧,我继续用我的 GET,POST ,不知道做微信接口的同行看到了会不会自惭形愧,居然没有学习大厂用 RESTful
        121
    noli   3 天前
    @cxe2v

    反正 v2 上发了帖就改不了。你愿意指出具体问题你就说,不想认真就别回。

    你要说 RESTful 规范不适合的时候强行用,真是好笑了——我做了什么 RESTful 的系统,又是怎么不适合的?
    或者我举了哪个例子,让你觉得 RESTful 不合适?
    怎么不合适你又不说,不好意思,不是你女朋友你老婆,我不负责体贴你。

    既然我举的例子你不服,觉得微信是王道,你说出个微信的道理来,有没有理大家评评嘛。

    觉得说不过、不值得提前撤,也是可以的。
    接受我的奚落就是了。
        122
    danielmiao   3 天前   ♥ 2
    @noli
    本来我是不想回的,因为这种脱离生产的为辩论而去做辩论,没有特别的意义。但是看到你这么酸的。。。。。

    我从主贴上看到您是驳斥这种 Json Envelope ,你希望通过只处理 http 头来解决问题。。。但是后续又提出“ HTTP 错误码是为工作在 HTTP 层的各路非业务设备看的 ”,那我的理解就是关于资源有无,应该是业务层,而非 HTTP 层的。。所以真心不知道你是什么观点。
    至于你说的:“ curl -i 就可以看到是哪个服务器发出来的响应了。 ”
    我觉得没问题,能解决问题,但是,如果不用这些方法,只是通过日志直接能判断服务的问题,这样的效率不是更高,只是为了遵循某个规范,而搭进去排查运维、开发的人力和时间成本毫无意义。

    至于你提的 2 大厂。。。只是代表了一种设计思想(错误码和 json 同时使用),但是并非强制标准抑或其他。


    国内几大厂以及主推微服务架构的 Netflix ,则推行的则是 HTTP 状态只负责链路层,业务错误由另外结构体处理。
    从 spring-cloud-feign 上来看,目前的方案是:非 200 的错误的处理方案是统一的 errorDecode ,也就是非 200 由处理链路层的方法去统一管理。

    所以说不管方案是不是纯血的 Restful ,贴近生产,符合实际,能提高劳动效率的方案才有意义吧。
        123
    noli   3 天前
    @danielmiao

    我知道你为什么会这么理解我的观点了。

    明确一下我的观点:
    0. 我反对只用 GET POST
    1. 如果只用 GET POST ,那么 GET 一个资源 ID 错了的时候用 404 会有歧义
    2. 如果不希望客户端错误理解 404 (并且将错就错),那么返回 200 和 一个 JSON 应该是可行的做法
    3. 可是这样就必须强迫客户端总是要解析 JSON ,并且如果真的是资源不存在的时候, HTTP 设备也无法知晓

    所以 3 就只用 GET POST 这种方式带来的隐忧,也因为如此我反对这种设计。
        124
    halden   3 天前   ♥ 1
    做前端的,表示 RESTful 这个东西应该是为了前端方便而来的。你可以说它是风格,但我觉得 RESTful 作为不是硬性的“标准”可能更加适合,因为我肯定希望后端全部按照这套东西来写 api ,这样前端可以用 js 根据不同的 code 做相应的反馈,状态码都是固定现成的,一套 js 只需要稍作修改就可以用在其他地方

    create(post) - return 201 / 409
    delete(delete) - return 200 / 404
    edit(patch) - return 200 / 204 /404
    read(get) - return 200 / 404
    replace(put) - return 200 / 204 / 409

    这一套可以应付大多数情况了,而且 201/204/409 的使用显然比单纯用 200/404 来得人性化

    我看楼上有人举『移动到文件夹 X 』的例子,很明显这个已经超出了 RESTful 所定义的范畴,你强上 RESTful 肯定不合适,但比如你 增删改查 设计成符合 RESTful 的架构,然后其他的再自定义这完全 OK 啊
        125
    lightening   3 天前
    @magict4 非常建议有空的时候真的看一下。 dhh 作为 Ruby on Rails 的设计者,很多思想都非常富有远见。而且他不像很多大牛一样是极端。他先介绍了 REST 风格到底给你带来了什么好处,也说了在什么情况下需要 make exception 。
        126
    cxe2v   3 天前
    @noli 第一啊,我并没有说你做的什么系统有什么问题,只是你自己前后矛盾而已
    第二,可能你语文不太好,不能体会字面背后地意思,那我现在说清楚,不要为了 RESTful 而 RESTful ,要看实际情况来
    第三,微信的例子,就用我最近要用到的微信公众号接口来说吧,它也并没有采用 RESTful 风格,而是定义了一个确定的 JSON 结构,然而我感觉在你心目中微信根本不算什么,在你眼中,要每天百万级的接口调用才叫牛逼

    还是那句话,你开心就好,我真是闲得蛋疼

        127
    juice   3 天前
    看看 fb 的 Graphql ,也是不错的一个解决方案
        128
    noli   3 天前 via iPhone   ♥ 1
    @cxe2v

    1. 前后什么内容什么观点矛盾了请指出。要不你看看 #123 是不是你自己误读了。说话说一半神惹人烦

    2. 什么实际情况请说明,别装 B ,说话说一半神惹人烦。

    3. 微信的接口确实没啥牛逼的。各家 sns 的 api 封装是我曾经做过的产品之一,各位写移动 app 调用的 sdk 可能有可能包含我的代码。所以我觉得我起码有调查过,你说它牛逼就因为它是微信?
        129
    wizardforcel   3 天前
    @noli

    > 你一直在说 http api 调度代价大,事实上数据库访问的代价更大,连接数基本上都是有上限限制的。数据库的调用逻辑更是测了又测。我扩张几台几十台 http server 简直是简单得不要不要的。

    就算真的要用集群,就必须用 REST ??呵呵。你们家 REST 还是跟集群绑定的??

    REST 的发明者都没你这么强硬吧??你是来布道的,但是大家的选择权也是很重要的。 REST 虽然优雅,但是我不喜欢就可以不用。
        130
    wizardforcel   3 天前
    终于扯到返回信息的处理了。。

    [按照 404 的语义,响应 404 是不对的: 因为客户端请求的 URL 实际上是正确的,只是对应的参数没有找到对应的结果 很多时候,就只能靠响应 200 然后返回空数据或者空对象来处理了。 ]

    你前面也说了,自定义错误码就能解决。(但是国内多数厂商提供的 API 是 200 + errmsg 这种方式,没你想象的这么简单)。

    [这样就会要求客户端,必须处理 HTTP 回复的具体内容,而不能只处理头部。]

    就算拿 HTTP 状态区分,对于成功的请求,还是要解析 JSON 的。反正 JSON 这块你绕不过去。

    [对于强类型语言例如 C/C++ OC Swift 写的客户端来说,恐怕就忍不住要问候服务端程序员一家了。]

    JSON 库的封装跟强不强类型没关系,跟是否存在反射有关系。 OC/Swift 的 Runtime 十分强大,所以把 JSON 变成对象是没问题的。

    至于 C/C++ 嘛,在互联网的服务端 /客户端中占得比重太少了,我设计个接口为啥要考虑它??那我是不是还要考虑一下 Delphi 、 COBOL ??
        131
    noli   3 天前
    @wizardforcel

    谁强迫你了?谁布道了?
    我在批评乱改 RESTful 规范然后又搞出自以为高明的设计。

    选择权很重要?
    我们不聊政治,按需遵守规范就是降低效率浪费人力浪费金钱,我觉得这些比什么鸟什子选择权重要得多。
        132
    wizardforcel   3 天前
    @noli

    你忽略了我上面那句话。

    mysql-cluster 是跟 REST 绑定的?? redis-cluster 是跟 REST 绑定的??

    谁告诉你用集群就必须用 REST 了??数据库连接背后就不能是集群??
        133
    noli   3 天前
    @wizardforcel

    我说了很多次,也贴了 Google Amazon 的做法,我不介意再重新说明一次我的观点:
    *** 自定义错误码是不够的,必须结合 HTTP STATUS ***

    而我帖子里面举的例子, GET POST 返回 200 然后 json 说有错这种做法,就是违背 HTTP 语义乱来的做法。
    情形就好像 TCP 里面明明发了 ACK 却想要对方重新发送一样鬼扯。

    “至于 C/C++ 嘛,在互联网的服务端 /客户端中占得比重太少了”
    当我说客户端的时候,你想到的是手机、浏览器;
    而我想到的还有 Proxy SERVER , CDN Server
    你只关心业务,我关心的是整个网络上的机器。
    所以视野不同,结论不同。
    如果算上我说的,你还会认为“ C/C++ 在互联网的服务端 /客户端中占得比重太少”吗?
        134
    noli   3 天前   ♥ 1
    @wizardforcel

    0. 数据库机器比 HTTP SERVER 价格贵得多。

    1. 当我增加面向客户的机器时,如果这些机器是纯粹的 HTTP SERVER ,那我就不需要考虑调整数据库集群,但同时带来更好的处理 客户请求的响应性能。

    2. 如果这些 HTTP SERVER 我能确保它们实现业务的时候,正确理解和使用 HTTP STATUS 语义,例如 GET 是幂等的, 200 就肯定是成功,这样的语义,那我就能确信它们能降发挥 CDN 的作用降低数据库压力。

    3. 遵守 RESTful 的规范确保 这些 HTTP SERVER 能够满足 2.

    所以没错,事实就是这么直接,信不信由你,现行的标准里面 RESTful 在集群上就是这么有效果。
        135
    Balthild   3 天前
    @noli 你找我要「优雅」的标准?哈哈,找错人了,这个词可不是我先说的哦,我只是顺着楼上某个人的思路向下走。
        136
    baconrad   3 天前
    ```
    「如果你有的只是一個鎚子,那麼所有的東西看起來都像一個釘子」

    「把一個熟悉的技術或理念強迫的應用於大量的軟體問題上」的概念已經被認為是一種反模式,一種編程時應該避免的實踐
    ```

    https://en.wiktionary.org/wiki/if_all_you_have_is_a_hammer,_everything_looks_like_a_nail
        137
    Cbdy   2 天前
    “不少程序员都是这么认为的”,第一句话,谁这么认为?
        138
    noli   2 天前   ♥ 1
    @Balthild @baconrad

    你看,我讨论问题的诚意在这里。
    我给出了一个例子,展开了这个例子,然后根据这个例子讲了我的看法。
    有人提出不同意见
    我反驳。

    而你们做了什么呢?
    只是在把一些看起来很有道理的话贴出来
    说了什么很有道理的话呢?
    “ XX 是好的,可是不是什么时候都是好的”
    “人是肯定会死的,但是不要急着去死。”

    不如我也送你一句话:
    解放思想,实事求是

    不用谢
        139
    noli   2 天前
    @Cbdy 我相信本帖种不少人表达了类似的意思,甚至说, GET 都不是必须的,有 POST 就够了。
        140
    gzq527   2 天前
    这是个找喷贴???
        141
    uzumaki   2 天前
    秀优越 秀大神还是找喷?
        142
    hysterin   2 天前
    讲道理,我是来学习撕 b 技巧的。
    真的受教了。感恩各位大神。
        143
    uzumaki   2 天前
    @hysterin 妹子 可以约么。。。
        144
    hysterin   2 天前
    @uzumaki 拒绝。
        145
    neurocomputing   2 天前   ♥ 1
    瞧你说的 HTTP 其实也不需要了

    直接 raw TCP 通信呗
    开头写上资源和动作 后面跟参数就行了呗
        146
    silva   2 天前
    @uzumaki 问个问题啊,在没有特定背景铺垫的情况下,直接论坛上看到个女的就约,有成功的可能性么?
        147
    ijustdo   2 天前
    我咋看都觉得应该是 nginx rewrite 该干的事
        148
    xcv58   2 天前 via iPhone
        149
    uzumaki   2 天前 via Android
    @silva 虎躯一震,王八之气一发,只要你说就有机会,不说,机会都没有,再说了,你不知道他是谁而已
        150
    silva   2 天前
    @uzumaki 积极乐观的精神真是让人欣赏。。。原来真的有人这么想的。。。
    受教了,谢谢啊
        151
    uzumaki   2 天前 via Android
    @silva 嘲讽么。。
        152
    silva   2 天前
    @uzumaki 怎么会,只是经常看到类似现象,有点好奇是不是真的可以约到罢了
        153
    noli   2 天前 via iPhone   ♥ 1
    @hysterin

    讲道理的话,我这种撕的手段只能在 v2 生存。因为这里的立场是讲有帮助的内容。

    遇到像你这样的回复,我肯定没招。完全是天外飞仙的歪楼,而在别处不一定属于禁手。
        154
    uzumaki   2 天前 via Android
    @silva 你有酒么。其实不能, but....这妹子我肯定能约上。
        155
    hysterin   2 天前
    @noli

    不不不,您误会了,先跟你道个歉。这里不是来歪楼的,确实是表达敬意。只是可能态度不太端正。

    事实上我是做品牌的,您的回复全程我都有关注。

    虽然内容准确与否有待商榷,毕竟是争议性话题,而且大家各有立场,无法说出个绝对正义。但是您的回复,非常精彩,公关级的撕逼。除了有几楼稍微过激之外,真的是很厉害。
    ----------------------------------------------------------------------------------------
    顺便回复 @silva 小伙伴,悄悄跟你说,别说论坛了,我曾经认识过一个妹子还能在淘宝约。。平台不重要,重要的是你想不想约。。想约就总有上钩的人的。。。
        156
    baconrad   2 天前   ♥ 2
    @noli

    那兩句話只是想提醒自己,不要再犯同樣的錯誤。

    兩年前看到 Restful 的設計方式後,真的覺得自己撿到了一塊寶,興奮地和當時合作的後端介紹它的規範和理念,然後討論著該如何導入之後的項目裡。

    但以結果來說我錯在太堅持,全部依賴 Restful 設計原則,導致任何需求必須把它捏成 Restful 能夠接受的樣子,還得告訴自己 Restful 果然很棒,什麼都做得到。

    「當時的我們就像拿著鎚子的小孩,所有的東西都想拿鎚子來敲。」

    Restful 可以解決大部分的需求,我同意,
    但不是所有需求都得用 Restful 解,即使它做得到。

    離題了,
    但這是那兩句話的原意。
        157
    silva   2 天前
    @hysterin 谢谢来自妹子圈的实例,我的世界观又可以刷新升级了。
    话说淘宝那个,妹子主动约应该比较简单吧。

    ------------------------------------------------------------
    @uzumaki 这么有信心,其实你俩本身就是好 CP 吧?
        158
    uzumaki   2 天前 via Android
    @noli 事实就是 当你用如果是纯粹的 xxxx 来考虑,就违背了现实因素。我还纯粹数据库呢。。要你这有何用
        159
    bloomy8   2 天前
    这帖子太精彩了,忍不住冒个泡
        160
    Nitromethane   2 天前
    Restful 只是 http 这一层面的~
    客户端浏览器使用 restful ,或服务端使用 restful ,模板都是解决工程问题。
    服务端调用其他系统的借口,当然还是习惯 RPC 和 Thrift~
        161
    bravecarrot   2 天前 via iPhone
    其实从模块儿设计的思想来说
    restful 是符合 高内聚,低耦合 的

    就拿 lz 的例子来说, url 分发的模块和逻辑处理的模块应该尽可能的分开,你设计了 add del modify and so on ,但是业务逻辑更多的时候呢,需要修改的时候怎么办?从 url 到逻辑代码都要修改。

    采用 restful 的方法,都到一个地址
    后端的人想怎么写就怎么写,不同的人写不同的模块,都处理 json 就行了。功能增加,功能修改都只需要改后台逻辑部分就行了

    最开始做东西 就按 lz 的思路做的,每一个操作都一个 url ,工作量非常大!后来了解到 restful ,简直是艺术
        162
    bravecarrot   2 天前 via iPhone
    搞错 lz 观点 尴尬😅
        163
    LINAICAI   2 天前
    然而大部分后台开发人员都不按照这个来,几乎都只有 post 和 get 。
        164
    thekll   2 天前
    RESTful 是一种针对互联网应用系统的架构风格( architectural style ),有非常明确的应用场景及要求。
    REST 化对系统性能、灵活性、统一接口、移植性、可靠性等方面都有好处。

    如果不以系统架构(客户端、服务端)的角度考虑问题,只考虑服务端内部如何方便实现,不考虑客户端,是没办法理解为什么要 RESTful 的。

    反对的,也应该拿出点干货。
    有些根本就不知道 RESTful 的目的。
        165
    lygmqkl   2 天前 via iPhone
    第一 如果一定要使用一个一定是 post ,而不是 get ,所以精简一些 post 就足够了。

    第二如果你觉得 get and post 对你同意重要,那么你肯定需要 put delete and option 。包括 resource 和幂等在内的一些概念真的很棒!

    最后国内有太多伪 RESTFUL ,合作过一些大项目出来的 a or i 工程师简单粗暴的觉得 post 可以代替 put 也是醉了
        166
    smallpath   2 天前
    百万级别的 api 调用次数很多?/手动 AC 扇子脸
        167
    lslqtz   2 天前 via iPhone
    post 同样可以理解为向服务器传递消息,通过参数来说明动作
    实际上,普通的带参数 get/post 单个请求能完成的 不应用 restful 多次请求增加负担
    优雅是一方面 负载同样重要
        168
    noli   1 天前
    @lslqtz

    不明白为什么 RESTful 对你来说居然是代表着多次请求才能完成普通 HTTP 请求。
    或许你就是哪种又不懂又要(有意或无意地)泼脏水的
    果然无知就是罪恶啊。
        169
    lslqtz   1 天前 via iPhone
    @noli 指的 move copy 等请求
        170
    noli   1 天前   ♥ 1
    @lslqtz

    我只是举了在我那个系统里面的做法为例子,并且是针对带有事务性质的要求,用基本动作的组合来描述一个事务。
    没有人说过 RESTful 语义做那种看起来是多个请求组合的方式就真的一定要发多个请求。
    既然你可以说的出“ move copy 等请求”
    想必用 RESTful 语义 POST a move POST a copy 也不是什么难题吧?
        171
    Balthild   1 天前 via Android
    @noli 抱歉啊,你又找错人了。
    你应该找一开始说「只是要优雅」的人去要优雅的定义,毕竟这句空话是他先说的。而且,我看你好像还回复了他来表达赞同,所以我相信你知道我说的是谁。

    邮件的例子,你举是举了,然而却搞出一堆什么事务啊队列啊之类的东西,越搞越复杂。如果不用 REST ,就是传一个自定义动词 move 的事情,显然比 REST 更优雅。
        172
    Balthild   1 天前 via Android
    手里拿着锤子,看什么都是钉子。
    殊不知排钉得用气钉枪打,用锤子只会把它锤弯。
        173
    noli   1 天前
    @Balthild

    那是因为我给了一把索尔的锤子。当然可以把所有东西当钉子了咯。
    事务和队列确实是业务需求,跟 RESTful 无关。
    因为你不知道实际上我做的事情是用 json 做了一个 DSL 来描述事务。
    这的确跟 RESTful 没有直接的关系。
    但如果不是 RESTful 的方式解构所有资源操作,你根本就不可能像我那样用 JSON 来描述所有的事务动作。
    你必须一个一个事务地去实现而不是像我写的那个系统那样,把要做的事务交给调用者来定义。
    跟你们这些靠勤奋的锤子比,我都不好意思了。
    1  2  
    DigitalOcean
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   鸣谢   ·   2230 人在线   最高记录 2447   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.7.5 · 65ms · UTC 06:34 · PVG 14:34 · LAX 22:34 · JFK 01:34
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1