Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

Web API 不该是 REST 风格

  过去的半年里一直在和一套 REST 风格的 API 纠缠不清。纠结到最后发现整个就搞成一坨了。今天坐在地铁上细细地思考了一番,突然觉得好像自己一开始就没走对方向。对于复杂业务的 API 设计,REST 风格确实是不合适的,下面我就来总结一下这些坑。
  REST 的核心在于无状态、面向资源。这两个核心思想都非常不适合 Web API。

无状态的坑

  在一般的程序设计中,「无状态」是非常棒的思想。然而这种思想却很难在 Web 上实现。目前 Web 架构中最健壮的授权机制是 HTTP Only 的 Cookie。如果使用 RESTful 就相当于要放弃这套最健壮的授权机制,改用一套 Access Token(将 Session ID 暴露给前端)的方式来实现状态传输。这会导致一些安全问题,比如页面上一旦存在 XSS 漏洞就会造成用户的 Session ID 被盗取,即使 XSS 漏洞能及时修复也无法挽救那些已经被盗取的 Session ID。
  另外我之前也稍微研究了下 Cookie 之外的状态存储机制,不过只是停留于理论阶段,感觉非常不靠谱。归根结底还是「无状态」不适用于 Web 这个问题。

面向资源坑

  何谓资源?资源即文件,在 Linux 的思想中,万物皆文件。Web 本身是可以接受面向资源的,因为 HTTP 本身就对面向资源友好。HTTP 的几个方法似乎也在告诉我们它操作的是资源。我并不反对在 Web 中使用面向资源的设计,反而非常推荐将页面 URL 以资源的形式来设计(URL 这东西本来就是「统一资源定位符」)。
  虽然 Web 页面可以以「资源」的形式设计,但是 API 则未必。因为 API 有很多资源外的性质,最典型的就是事务和回滚机制。资源访问几乎都是幂等的,而 API 访问则有一半是非幂等的。所以我认为 API 不适以面向资源的思想来设计。

更深的纠结

  URL 是「统一资源定位符」,而 Web API 是对「资源」不友好的。基于 URL 设计的 API 迟早都会变成一坨奇怪的东西。然而在 Web 上如果脱离了 URL 就会出现缓存等一系列坑。于是我陷入了纠结,请让我静静地想一想。

网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^