这排版……忍不了……

@est 你说的问题存在，所以说 RESTful 不是银弹。

RESTful 实体的思考方式有利于梳理大部分的业务，特定场景用别的方案，用呗。怕的是 API 设计一味造轮子，纯把业务搞乱。

看看主流 Web 框架对它的支持，我也乐于捧 RESTful 的臭脚。

@est “发明 RESTful 的人就是个做外包忽悠人的。”

真是什么话都敢说。不知道你跟 roy 比，谁是做外包的！

“ Roy Fielding 的毕业论文。这哥们参与设计 HTTP 协议” 出处： https://www.zhihu.com/question/28557115

资源 != 表
资源 == 业务场景实体

业务场景实体的转换( A->B )和修改( A.a = 2 )都可能导致表修改以及大量业务逻辑。

问题 1: 去结算
根据购物车的数据 POST Order 就好，"更新订单资源，创建该订单对应的物流资源，更新用户余额" 这些都是后端逻辑，前端不要管，管了也不安全

问题 2: 有些场景会有接口 1 调完调接口 2，一般都是接口设计不合理，比如问题 1.

RESTful 不是银弹，但能满足国内 80% 中小企业的绝大多数场景。而且绝对比开发随意定义的结果好得多。先学会，再去喷……

字节跳动

刚又续了一年，支持下

ELK

太累，ELK 试试

https://www.zhihu.com/answer/409860681
知乎答了一波

@lqzhgood 谢谢你的回复。

视频中也有说，那是重启时间，不是日常使用从待机状态启动的时间。正常启动 2s 内。

有广告我是 1s 也忍不了。

肯定第二种。

JSON 标准支持 bool, number, string 就应该合理的使用。使用第一种方案的的确解决了一些问题，但不是合理的解决方案。（设计合理的解决方案要在遵循标准基础上）

简单罗列一些思路：
输出端（服务器）要符合标准，死磕定义
- 合理定义类型：bool, number, string
- 改用 bool 的用 bool，改用 enum 的用 int
- 规范处理 null, "", 0, [], {}
- 常见错误：非数值定义，如手机号、ID，不应该用 int，应该用 string


接收段（客户端）要做的：
- 合理处理类型见自动转换：int <-> float <-> String，包括自定义的：如 iso8601string <-> Date
- 合理处理空、空值：
- 避免 float 精度丢失，数值移除
- 如果服务器输出 json 符合约定，后续业务变化客户端 crash，这锅该客户端背


这些不想清楚，一股脑儿用 string，low ！

@lqzhgood "小米开机时间（有广告）比 sony （无广告）还快"

这个太扯了，不了解别乱说。

对电视没追求就小米，有追求就买得起最贵的索尼

@shinianku 说 iOS 第一代是微创新……你还真敢说……

来看看当年最前沿的 Window Mobile 开发人员怎么说的： http://daily.zhihu.com/story/4261091

还有，第一代不叫 iOS，叫 iPhone OS。

系统都 android tv 了，不要用就好，很多应用也可以禁用掉。

具体哪款，量力而行就好。

搜一下就有了：

The first question people are likely to ask: If the most recent version of MySQL was a 5.x release, why's this one 8.0? For one, version 6.0 was canned as part of the transition to "more frequent and timely releases of the MySQL Server." Version 7 was reserved for the clustering version of MySQL. That leaves 8.x as the next major version number for the common use-case version of MySQL.

https://www.infoworld.com/article/3119258/database/mysql-80-more-unicode-less-hassle.html

拆分的目的是什么，想达到什么效果？为什么不用一个 scroll view 解决？

昨天的帖子看到没回，今天的内容更扯…… LZ 你开心就好