• 理解本质的 REST at 2018年01月17日

    整个互联网上对于REST的迷惑,最终就落到了这个“超媒体作为应用状态引擎”(HATEOAS:Hypermedia As The Engine Of Application State)上,其他几条都没有问题。而按照REST原意,没有这一条就不能叫做REST,因为它是“约束"。

    在尝试了好几个项目,以及看了很多资料之后,我还是非常困惑如何在API方面做到这一点。这一点似乎是专门为面向人类的HTML阅读器:浏览器而设计的:因为如果你把链接(超媒体的要素)放在文档里让客户端使用,那么前提是客户端知道如何去使用这个”链接“。而“客户端”并不是一个人而是一个程序,它如果知道如何去使用这个链接,那么这个链接对客户端来说就是已知的了:我写过这个链接的代码,测试过它。超媒体给我的唯一信息,是我在此时可以或者不可以去使用这个链接。

    举例说如果我有

    <!-- GET /posts/1 -->
    
    <post>
        <title>一个大新闻</title>
        <content>...</content>
        <link rel="like" href="/posts/1/like" /> <!-- 为这个帖子点赞的链接 -->
    </post>
    

    试想开发一个客户端的的时候,如果我看到这个链接,那么我的客户端需要能完全理解这个链接的含义:为这个帖子点赞,于是我必须事先写好,能像用户说明这个功能的UI,比如一个点赞按钮,并且我需要用适当的手段向我的用户说明这个按钮的意义,而这一切都必须是事先准备好的。这样来说,如果API更新,加入了一种新的动作,例如关注,那么在我客户端不更新的前提下,我是不可能支持这种新的动作的。

    然而作为浏览器,它的使用者直接是人,情况就大不一样。因为负责说明这个新动作关注的任务,就已经包含在这个返回的文档里,人类看到这个文档(浏览器的渲染)后,就已经能理解这个新动作了。

    这样一来,虽然说我在编写客户端的时候,没有事先写死一个链接模板比如/post/:id/like,但是我对这种类型的链接,必须是实现有所准备的,因此虽然我可以处理超媒体,但是我能理解的超媒体控件数量,取决于我客户端软件的版本。这样一来,我认为超媒体最重要的一个意义就失败了,就是允许客户端使用超媒体去发现API新的能力。

    如果是这样的话,那么我就无法理解为什么这一条是REST的一个必备条件。理论上,在上面例子当中,点赞这个动作,我可以依赖服务器在运行时给我返回一个动态的链接,但是这对客户端来说,仅仅是链接的地址有无事先约定,而链接的处理方式则是必须事先约定好的。实际使用的时候,这个链接地址动态变化所产生的不同是微乎其微的。

  • 2018年招聘,欢迎捧场

  • 这也太慢了

  • #9楼 @chenge 是我说错了,我本来应该指的是他说Don't Repeat Yourself会增加耦合度。至于Convention over Configuration他本来意见也比较弱

  • 没有觉得Rails跟图上画的一样,跟业务逻辑交织在一起,完全就是个错误的论断。

    刚看了下他的一些文字,,他连Convention over Configuration都可以站出来反对,说这会“增加耦合”,实在是无语。估计这位同学是J2EE的卫道士——不依赖任何外部库,所有东西都手写,方法都是静态的,最符合其要求。

  • #6楼 @flemon1986 目前来说在rails里面,仍然是coffeescript比较顺畅,配置容易,同时兼容内嵌和外联,跟sprockets集成的好。Coffeescript解决了低版本JavaScript的一些棱角,虽然不如ES6先进,但是在Rails工具链上胜出。

  • #4楼 @flemon1986 Vim党万年问题:Coffeescript的优质高亮。我看了一下coffeescript.vim,暂时没太明白

  • #1楼 @greatghoul 这两个很有帮助。Vim里是Rails.vim已经包含着两个功能了