@shilyx Upgrade 不是 http 发起？

运维：你们都让开。我来背锅。

@changnet 也是不一定的。TCP OOB 了解一下。。2333。

国内做技术的就是喜欢瞎 jb 发明名词，然后另一拨人对名词后面的需求又瞎 jb 起哄。

分包 粘包 这个其实是 layer 7 应用层更上面的需求，其实也应该严肃对待。

http 严格的来说属于 OSI 7 层了，websocket 至少 8 层了。websocket 里套业务逻辑应该 9 层了？

@e8c47a0d 粘包 这个倒是实实在在的伪概念。。国内游戏开发师徒制+百度流传出来的。。。

@changnet

收到 1 请求，worker 开始处理 1，暂时不返回
收到 2 请求，worker 开始处理 2，立刻返回
worker 返回 1 请求的结果

这个时候如果你是客户端如何区分 2 个返回？仅靠顺序可能嘛？

谷歌回来就不备案了？天真。

@ericls 看逻辑。如果只是 hello world 当然可以保证顺序。但是如果 websocket 架构可以异步返回，那么耗时长的肯定在后面返回，就没有顺序了。
@e8c47a0d packet collision 是半双工的概念吧。。websocket 是全双工的。

LZ 的意思是 websocket 不是严格的 请求 - 响应，而是有可能连续请求中，夹杂着响应。

那么答案是：是的。websocket 是一种双向流协议。你得考虑这种情况。

其实原始的 http 也会有这种情况，只不过反向代理和 web 框架帮你把这事儿处理了。

uwsgi 一把梭。

@newtype0092 我也是这个做法。PUT DELETE 都是笨蛋设计。

找缺点很容易，但是能发明自己语言的，都先点个赞。

@newtype0092 不矛盾。对资源的操作太丰富，所以规定 2 个大类就够了。4 个 verb 明显不够。比如 OPTION 在实际中就少不了。。。DELETE 也是有 2 意的。其实很多删除并不是删除。而是设置一个已删除的 flag。
@zvving 其实我比较支持对 资源 的梳理，我主要反对 REST 里把 verb 定义成 4 种 这种做法。太死板了。

@unforgiven 其实就算 db 里一张表，我觉得现代的用处也远远超过了增删改查。

比如 upsert。 比如 on duplicate key update。比如 update a = a +1

这些都是 fetch-then-update 的操作。有些还得做线程安全。这些我觉得都不能简单的概括。RESTful 根本不能覆盖这些情况。

就拿最简单的 GET URI 操作来说，页面访问量计数器算不算状态的改变？多次刷新 GET 能否保证幂等？这些问题都是各个人都有一套自己的答案。

RESTful 是属于蛮荒时期一个方向性的指引，是个不错的大框架。但是现在应用场景那么复杂精细还用这个框架去套就不对了。应该具体业务用不同的方案。

@zvving

http 也并不是什么好协议。或者说 http 并不是什么场景都适用的。Roy Fielding 也不是什么好人，或者说他的一些观点在当时可能有用。RESTful 发明的时代是 http 1.0 时代。那个时代的东西被淘汰的太多了。他发明的 SOAP 你们今天还有人用嘛？

Roy Fielding 后来去了 Adobe，按照他老人家的思路去搞了 CodeFusion。这玩意你们有做过嘛？简直各种别扭。


为毛 RESTful 就那么多人捧臭脚？搞不懂。RESTful 在过去唯一拿的出手的就是 WebDAV。其本身就是各种安全和性能问题一坨浆糊集大成者。其本身就是个 leaky abstraction


@unforgiven

RESTful 在上古时期(UUCP 还是个事儿的时期)可能有用，但是现代复杂业务场景下就是胡闹。

@Phariel 我觉得体验不好。。。每次都对不准菜板。。

@rrfeng 正解。try_files。

@slince 我觉得 GET 读 POST 改就够了。何必分那么多。

GET /order/status
GET /order/list

POST /order/submit
POST /order/cancel
POST /order/close


RESTful 还区分资源的单数复数，真是没事儿找事儿。

发明 RESTful 的人就是个做外包忽悠人的。世界上对资源操作的行为这么丰富，非得必须封装成对资源的增删改查，还仅限这四种？有病。