一样，连 mac 各种卡。
一带回家就效果好多了。

@Marcustar 笑鸟。。下次来推广记得换一个 id

身份认证这种没有什么技术含量的东西也要来推广吗？

@wysnylc
这里的 SimpleDateFormat 并没有竞态问题，为什么不能用？？
阿里规范是让你不要在线程不安全的情况下使用 SDF，而不是让你在并发环境下不要用 SDF。
你也是半桶水。

imessage 和 facetime 用不了。

@qinyongr 零售店看人看货的。便宜点的小配件无损坏直接给你退了，手机电脑平板肯定需要检查一下序列号的。
网上商店售出的每一件商品机身或者包装上都会印有唯一序列号的。

没这种序列号标记的，退货早就被人调包玩坏了

核对的。

前端无法保证 100%的安全，你能做的，也只有提高破解 /反编译成本。
简单点，代码混淆。
复杂点，核心加密模块用 c/c++。
再复杂点，服务端一起配合加入风控模型。
但是不管怎么搞，对于服务端来说，数据逻辑的正确性要由服务端校验，以要保证业务的正确性。

同样深圳联通。。。imessage 无法激活。
换成浙江联通和浙江电信，又能激活。。

目测是广州联通把 imessage 激活的 sms 号码拉黑了？

看一下，MappingJackson2HttpMessageConverter 和 JacksonAutoConfiguration
目测是配置没有生效。

1. 看你前段返回时候序列化是用的 spring boot 自带的，还是自己另外建的 JsonUtil
2. builder.serializerByType(LocalDateTime.class, localDateTimeDeserializer()); 这个 builder 的来源是 1 里的哪一个？

楼主我真建议你去看下心理医生。

> 作为一个程序员，心里不宁静的时候，怎么办？
> 如果你老家是三线城市，你在一线城市工作，你想回老家工作吗？或者你敢吗？
> 妹妹和当年的我一样，高考落榜了。
> 你是一名理想主义的程序员吗？
> 马上就要高考了，你还能想起来当年自己高考的样子吗？
> 520，摆脱单身重要，还是立业重要？
> Lombok 到底应不应该使用？
> 五一，你要去参加婚礼吗？
> 在洛阳做了 5 年的程序员，感觉荒废了！

楼主你是十万个为什么吗？

拿本书压平就行了

@WilliamYang 哦？是吗？你把返回页面这么分 html 和 api json 那说明你不懂 restful 了。
restful 返回的是资源，资源不分 html 还是 json 或者还是其他。
资源有多种展示格式，html 页面是一种、application/json 也是一种、还有很多 xml、影音视频……。服务端根据客户端 accept 头选择返回需要的格式。

主题讨论的是 restful url 以及返回的 http status 404 相关的，我为什么不能用普通 html 举例？

@sin30
得了吧你。
restful 本身只是一种设计风格，不是强制的规范标准，到你这里就变成了 200 党冥顽不灵了？
现在 graphql 出来，过几年你是不是又要拿着 graphql 来喷 restful 了？

http 接口怎么定义本身就是自己团队的约定。整天 github 挂嘴，是要把 github 当成神来供奉吗？

微软 office 团队的页面，https://www.office.com/AAAAAAAAAAAAAAA 类似这种直接 30x 跳转回首页，不用 404。
苹果未登录用户访问订单详情页返回 303 而非 403 未授权。
youtube 视频播放页输入一个错误的视频 id 直接返回 200，而且还提示视频无法播放而非视频未找到。
你挂在嘴上 github api 里，用户个人设置里的一堆 api url 带了 set/update 之类的动词，完全没有照 restful 描述的把动词放在 http 协议里。

这些大公司都有自己的 api 设计风格，按照你的 restful 标准，微软、苹果、google 都是辣鸡是么？连个 url 设计成 restful 的能力都办不到。

无知不可怕，非要拿一个标准 /设计风格把自己给圈起来，然后教育别人，跟井底之蛙没什么区别。

能竖屏

另外再补充一下为什么会将请求状态分为 http status 和 error code 自定义错误码两级，是因为在请求没有进入到业务 controller 时，请求可能会经过 waf 高防、nginx squid 等不同网关，每一个网关都可能会出错，而且每一个网关返回 http status 时，他们的格式都是不尽相同的，有的是 html、有的是 json、有的是 plain text，前端这边没办法做统一解析处理，因此对于在没有进入 controller 业务层以前的非 200 status，说明这次请求是失败的，前端这边只能根据 status 做粗的分类进行用户提示。

如果 http status 为 200，说明请求能顺利进入 controller 层，那么这时候返回的 json 格式完全能保证由开发者控制，前端也能顺利解析。

举个例子，某个 url 路径 GET /api/user/1 , 产品需求是，如果没有查找到这个 id 的用户，那么前端展示后端返回的错误提示。

在整个 http 请求过程中，出现 404 的地方可能会有哪些？
1. nginx 没有配置正确，返回了 404 的错误，response body 是 html 格式的 not found
2. 业务代码没有找到 id 为 1 的用户，返回了 404 错误，response body 是 json：{"code":-1,"msg":"用户未找到"}
3. CDN 回源失败，返回 404 错误，response body 是 html 格式的 404 页面
等等等...

假设发生了 404 错误，前端 js 代码 onerror=(resp)=>{if(resp.status==404) {....}}，这时候你需要展示 404 相关的错误，你改怎么展示？格式内容不定，完全无法解析。

如果我们把上边的 2，改成 http status=200，前端判断到 status==200，那么就可以放心大胆的根据 code 和 msg 去做数据展示和错误展示，因为只要是 status==200 的，完全能保证返回的内容格式是预期的。


restful 提出来的时间是 2000 年，到现在已经快 20 年了，现代互联网云服务的 web 服务器架构和 20 年前已经相差很大了，
http 承载了更多的复杂业务和功能，已经不是 20 年前 web 1.0 那种 增删改查 PUT DELETE POST GET 就能满足需求了。

没必要把 restful 奉为圭臬，等你系统做大做复杂了，restful 怎么设计 url 符合规范会把你搞得纠结不已。
普通 get/post 完全能满足需求。

至于你说的 http status。我只想说，这个完全就是个人喜好 /团队规范的问题。
就个人来说，我喜欢 error_code 的方式来表述业务逻辑上边的错误，类似根据 id 获取资源不存在、用户余额不足等等都属于业务异常这个范畴。

http status 是用在什么地方呢？我一般会用在请求还没进入业务代码的这一层，比如我用的是 spring boot，前边有 nginx 做前端，nginx 上边的 403 无权限、500 内部服务器错误、502 网关异常、以及 spring boot 404 路径不存在、400 requestparam 参数不符合格式、405 method not support 等这类没有进入 controller 业务逻辑代码的错误统一使用 http status 做表述。