如题,我目前就想到一个,后端写一套 API,前端写一套对接 API,工作量大,这是一个痛点,还有其他的吗?
1
waytoshine OP 找了个类似的回答:
将后端设计为 API 有过度抽象之嫌,巨大的灵活性同时也意味着巨大的复杂度; MVC 中的一些内置特性将变得无用武之地,例如与角色和认证相关的功能都要重新设计; 为了保证 API 调用的安全性,必须设计某种令牌系统,在每次 API 调用中都要附加相应的令牌; 整个程序中的每个功能都必须编写一个对应的 API 调用; 在 API 中无法利用接口或抽象类等工具,像 WCF 这样的框架对于接口的支持非常有限; 在桌面或移动应用中通常要避免细粒度的 API 调用,因此不得不为支持这些系统创建一些批量方法或粗粒度的方法; 这违反了 YAGNI 原则,除非你已确定要同时支持多种具备相同功能的应用,否则只是无谓地增加开发工作量; 由于无法实现端到端的单步执行,调试变得非常困难。 |
2
CODEWEA 2020-09-01 18:36:45 +08:00
想的太多,做的太少
|
3
waytoshine OP 磨刀不误砍柴工,做好功夫再下手
|
4
MeteorCat 2020-09-01 18:46:28 +08:00 via Android
先落实好功能呀,你功能都还不知道就开始分解业务了?
|
5
love 2020-09-01 19:21:20 +08:00
网站的 API 不能用 Cookie ?这和传统写法有什么区别??只是输出 html 改 json,把渲染提到前端来配合现在的前端框架
|
6
jones2000 2020-09-02 01:59:12 +08:00
动手做了以后才知道。
|