为什么一些前端不喜欢 Restful Api？

做过不少系统架构，全栈、前后端一起设计，我认为至少在部分领域restful可以扔了。

第一个被淘汰的是URI风格，主要是现在都是纯JSON请求和返回，例如post一般情况下id都和JSON放一起提交了，就没URI的必要。然后既然post都润了，那get、put、delete也一样了。且在js代码里面单独为URI设置参数也不好看，现在代码一般如下：

post('/console/modify-user',{id:'abc',name:'张三'}).then(data=>{
 //do something
{).catch(err=>{
 //
})

还有个重要原因，现在用typescript，可以用url字串查找定义好的接口，实现代码联想。动态url就很讨厌了。

第二个是http方法风格，有人说是url太多了才需要restful风格，我们这个领域恰是因为同等原因放弃restful风格。我们的风格是调用路径尽可能短、url尽可能表述更多的信息，类似这个样子

import { post } from './ConsoleAPI'

import { post as srmPost } from './SrmAPI'

post('/console/modify-user',{id:'abc',name:'张三'}).then(data=>{
 //do something
{).catch(err=>{
 //
})

srmPost('/srm/modify-user',{id:'abc',name:'张三'}).then(data=>{
 //do something
{).catch(err=>{
 //
})
  1. 仅剩 get post。
  2. get post 都预定义好了url和对应的请求、返回类型，实现代码提示。
  3. url信息量大，能表述模块和具体的动作，阅读轻松。
  4. 调用路径短了，因为url即是方法名，少了无用封装。
 
[捂脸]我也觉得URL短好处很多，post在一个事件的处理上不要太方便
 
 
 
 
相当于json rpc了，我也喜欢这种风格[大笑]
restful 属于简单curd的落伍设计，API 应该interface化，API只需要关注函数命名，出参和入参 就够了，其他的约定都是多余的认知负担
 
作者：linlol
链接：https://www.zhihu.com/question/60742445/answer/2880223713
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

难道后端喜欢么...restful只适合真的适合restful的东西，比如对应一些静态的资源的存储，修改，读取，除此之外都是生搬硬套

 

给出一堆接口，同一个路径get put post全部实现一遍，还要把大量信息直接暴露在URL，需求如果迭代的慢还行，如果迭代太快，或者需求太复杂，非常容易出现表现能力不够的情况，在这个情况下post 然后带一个复杂的json request body比它强多了

 

REST主要的好处是当需求是描述/表达资源的时候特别原生，在那部分情况下用restful表达会很容易懂，比如Jupyter server，它什么/content /kernelspec /sessions 是用rest，但是当做一写别的事情，比如/login /logout的时候，人家也没有犯傻逼把api设计成 POST/PUT /lab/user 这种类型啊

 

REST本身不是个坏事，但是为了rest去硬套rest，在不适合rest的地方强行编rest的范式，那就tm坏透了。在这种情况下如果团队觉得不应该有多种API范式，那rest和get post写一切之间做选择，必然是抛弃rest啊

 

还有就是restful本来就是00年的老玩意了，那年网页还都是静态的资源，JS没成为浏览器上的事实语言，3721还没开始劫持各位的主页，我家的电脑还没联网呢... 人家再牛逼也只能去想象，去假设未来的互联网可以干啥，今天都2023年了， 各位的手机里都内嵌了几十个浏览器应用了，与时俱进一点，网页不是资源是应用

posted @ 2023-10-23 23:40  China Soft  阅读(82)  评论(0)  编辑  收藏  举报