V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
noli
V2EX  ›  程序员

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

  •  
  •   noli · 2017-02-15 12:59:26 +08:00 · 40874 次点击
    这是一个创建于 2849 天前的主题,其中的信息可能已经有所发展或是发生改变。

    不少程序员都是这么认为的,基于 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 写的客户端来说,恐怕就忍不住要问候服务端程序员一家了。

    更重要的是……

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

    全文完,欢迎拍砖。

    207 条回复    2018-09-01 23:44:06 +08:00
    1  2  3  
    noli
        201
    noli  
    OP
       2017-04-19 11:43:50 +08:00
    @Balthild 只是你读的大学以及其同类必修马列毛邓好吗。这世界上又不是只有必修马列毛邓的大学。

    你首先给 REST 树了一个不存在的靶子让自己 YY 开火: REST 本来就只是在基于请求答复、基于 HTTP 的模型上有优势。我从来没有说过 REST 能解决任何的问题,而你也没有描述一个 REST 预期可以解决的问题。

    我一直在说,这么高的楼层里面讨论过的,大多数人所实践的做法,不是不 work ,而是 REST 在这些问题上可以解决得更好:好处在与,如果系统规模扩张后, REST 的做法有助于保持低耦合高开发效率,而不是说这些做法在其所在实践环境中效率不够。

    鬼知道你理解成什么东西了,什么全称命题、任意场。
    Balthild
        202
    Balthild  
       2017-04-21 20:18:18 +08:00
    @noli

    1. 必修马哲是国家政策规定的好不,除非你不是国内读的大学。鉴于你没有强调,我默认你是国内读的。

    2. 你难道不是自己说过,没有什么是抽象不成资源来给 REST 解决的吗?

    3. 我一直说的就是「而是 REST 在这些问题上可以解决得更好」这一个命题不一定成立,要看具体场合。

    4. 已经说过了,是「任意场合」打少了一个字。至于全称命题,类似「所有 XXX 都 YYY 」就是全称命题,这算高中水平的知识。
    aaronlam
        203
    aaronlam  
       2018-03-09 00:50:35 +08:00
    突然看到一个别人的一个问题,想了想好像的确是他所说那样,不知楼主怎么看这个问题呢?谢谢!

    大神,我一直存在一个问题就是 http 协议的几个动词是不是够用?因为你上面提到了说 get post update delete 是几个数据的元操作,那么请问如何执行比较复杂的操作呢?因为 mvc 开发模式中比较重要的 controller 都是用动作 action 来驱动的。比如我需要实现两个数相加,按照本能设计的 url 就是 ../add/num1/num2,这样就出现了动词了,这是违反原则的
    noli
        204
    noli  
    OP
       2018-03-09 17:53:10 +08:00
    @aaronlam #203

    可以参考栈式虚拟机的设计思想,将一系列的运算指令(运算 API 调用)视作往计算堆栈上 push 一个 op。
    于是,调用某个 API 可以在 RESTful 中这样表示:

    1. 操作资源是某个特定的堆栈

    2. POST 一个 Op, 例如 add, 其实现就是,在堆栈上读取(Pop)一个现存数据作为 add 的一个操作数,以及 从 post 请求中得到的 另一个 操作数。
    ybark
        205
    ybark  
       2018-09-01 13:09:54 +08:00
    上面一大堆撕 b 回复,看了以后很客观的觉得是浪费时间。我想,作为一个正常的靠谱开发者,对 restful 不可能不产生一种排斥和别扭的感受。个人觉得以资源为中心组织 url 很受用,但是非要让业务逻辑去依赖 http 协议中的语义我 tmd 就是不爽(包括 http method 以及 status code )。
    这里有一篇文章为我这种不爽提供了很靠谱的解释和出口: https://eggggger.xyz/2017/01/04/restful-api/

    无意争辩和钻牛角尖,我认为开发者的心态大概应该这样:
    透彻的理解你的问题,然后用你熟悉的技术和方法解决问题赚钱;
    如果在解决问题时发现你正在用的技术和方法不熟,那就继续搞明白,如果觉得不爽,就用你认为正确的技术和方法继续解决问题并赚钱。
    在解决问题并赚钱的这个大目标上,用还是不用 restful 基本上没什么太大的决定性影响。
    ybark
        206
    ybark  
       2018-09-01 13:16:42 +08:00
    觉得时间太特么多的也可以看看“ RESTful APIs, the big lie ”原文的撕 b: https://mmikowski.github.io/the_lie/
    noli
        207
    noli  
    OP
       2018-09-01 23:44:06 +08:00
    @ybark

    为什么会产生撕逼,一部分原因固然是相互不理解并且相互指责。
    而另一部分的原因则是——存在境界差距的人之间确实是很难相互理解的。

    非要讲一句非常笼统的话就是:
    软件工程,是一门可以用工程结果来评判正确性的哲学。
    因为他同时涉及思维合理性和工程合理性。

    而在有些问题上,思维不合理性导致的工程不合理的后果并不是那么容易看得清,需要经验去补——而有些人不认为这些经验是对的。

    事情就是这样。
    1  2  3  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4367 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 32ms · UTC 04:07 · PVG 12:07 · LAX 20:07 · JFK 23:07
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.