+
 新版
2016-10-24 07:33

引用来自“Xiao_f”的评论

REST就是自己找虐,怎么看都是HTTP作者看当初设计的PUT,DELETE 被人遗忘感觉没面子,发了个什么论文找回面子而已,劝大家选择还需要谨慎,别把规范当圣经,有时候它根本就不适合复杂业务功能的系统

引用来自“南漂一卒”的评论

HTTP/1.1 正式发布于 1999年中,RESTful API 论文发表于 2000年,不要乱讲~
DELETE PUT 1.0时就定义了哦,HTTP当初设计的时候还完全是静态页面的思想主导,作者万万没想到http能承载起当今复杂的webapp,所以资源主导api设计的适用范围是有限的,根据系统类型选择api设计方法很重要,不能一概而论,只能说互联网最擅长炒概念,很多公司用REST甚至是为了卖点宣传产品,这不是本末倒置?
2016-10-23 21:46
GraphQL 很坑的哦,和REST一样坑。客户端想要什么数据就整合给他,通常很难。
服务端程序不好测试的。
2016-10-23 21:35
结构很不错,但是实现成本较高,商业采用有待考究。
2016-10-23 18:34
关注一下
2016-10-23 17:23
如果用于外网Restful更容易权限控制,如果随意让客户端查询,不注意就会被读取到重要数据。
2016-10-23 16:09

引用来自“Xiao_f”的评论

REST就是自己找虐,怎么看都是HTTP作者看当初设计的PUT,DELETE 被人遗忘感觉没面子,发了个什么论文找回面子而已,劝大家选择还需要谨慎,别把规范当圣经,有时候它根本就不适合复杂业务功能的系统
HTTP/1.1 正式发布于 1999年中,RESTful API 论文发表于 2000年,不要乱讲~
2016-10-23 15:59

引用来自“Xiao_f”的评论

REST就是自己找虐,怎么看都是HTTP作者看当初设计的PUT,DELETE 被人遗忘感觉没面子,发了个什么论文找回面子而已,劝大家选择还需要谨慎,别把规范当圣经,有时候它根本就不适合复杂业务功能的系统
如果rest不合适,有什么合适的吗?
2016-10-23 12:37
REST就是自己找虐,怎么看都是HTTP作者看当初设计的PUT,DELETE 被人遗忘感觉没面子,发了个什么论文找回面子而已,劝大家选择还需要谨慎,别把规范当圣经,有时候它根本就不适合复杂业务功能的系统
2016-10-23 12:01
其实, 我很多年前在做REST API的时候, 就处理过这个问题
2016-10-23 11:11

引用来自“Iridium”的评论

厉害!只是没想到 Rest API 相关技术发展这么快!我司在还理论上讨论过用 Rest API 重构网站,看来可以跳过它,直接用 GraphQL 重构了。
GraphQL 只是补充而已
2016-10-23 09:59
因为 rest, webservice 什么的全是垃圾.
2016-10-23 09:42
这种技术是怎么实现的呢?
2016-10-23 09:31
厉害!只是没想到 Rest API 相关技术发展这么快!我司在还理论上讨论过用 Rest API 重构网站,看来可以跳过它,直接用 GraphQL 重构了。
2016-10-23 08:45
话说昨天刚刚纠结了这个问题,恰好也研究了GitHub的API
2016-10-23 08:31
厉害呀,但是怎么调用
回复 @
{{emojiItem.symbol}}
返回顶部
顶部