https://i.imgur.com/2umlPuY.png

截图给错地址了 https://i.imgur.com/wgnukxM.png

https://i.imgur.com/WyJtjIO.png

这里不是还开了个后门吗？
如果您有兴趣在未来几个月内收到有关您的非企业旧帐户更多选项的更新，请填写以下表格： https ://forms.gle/RcYKnJuSC6h7YXgcA

您将能够在 2022 年 7 月 1 日之前和帐户暂停之前评估此选项。

https://imgur.com/a/2c2VT35

深信服 AF 8.0.35 当前版本:8.0.35

@SteveWoo 感谢提供宝贵从业经验

@Joker123456789 ？？？弟弟你在说啥？ restful 和 RPC 是两个东西呀
RPC 规范并不是对 http 的，RPC 本身就是跨越了传输层和应用层的存在。
restful 是对 HTTP 中 web api 开发中的规范，http 可以理解为是最常用的承载 RPC 的通信协议之一
不管是 TCP 还是 UDP 甚至 ICMP 都可以设计 RPC ，我这样表达不知道说清楚没有

你要再用 HTTP 再去实现一次 RPC 的想法，有没有问题？
我前面已经表达了，使用了 HTTP 除非是不依赖常规浏览器，又由于环境限制必须使用 HTTP ，否则基于 HTTP 设计 web api 还是要应该遵循 restful
这不是教条 restful 本身就是实践出来的东西。你非不遵循 restful 没问题，你知道这样做是不规范的就 OK 。
明明业内有推荐规范，为什么非要自己去摸着石头过河呢？简单的举例 GET 和 PUT 在失败后是可以允许自动重试的，POST 作为大多数时候作为新增数据或者过程变更的操作可以随便发起重试？重试、限流、容错这些基本功能，你们的系统里面都没有的吗？都用 RPC 自己从头设计一遍？

------
嗯，为什么今天还来扯这个，今天甲方来电话，说是防火墙厂商表示不支持目的地 IP 放行，要么全放要么全关，请我们准备好和深信服的实施供应商现场对线~

@shyangs @Joker123456789 有点反智了哈，我认为在实际过程中，怎么做是一回事，但心里还是要知道什么规范的，什么是不太规范的，我前面说了，如果真的 http 不适合你的项目，又非得 B/S 化建议直接使用 Websocket

@patrickyoung 感谢哈，就是直接给怼回去了哈，我在前面的帖子中已经说了后续的处理了

@lesismal http 是无状态，不管什么原因，选择了这个协议，就该按这个思路来。除非是特殊原因的变相使用，把 http 当承载协议。否则设计系统通信的时候，就该按无状态设计

@0o0o0o0 我们的整个部署环境就没有 dva 这个东西

@lesismal 我们后端就是 go ，echo+gorm,后端迭代特别顺滑，现在有点趋势上的包袱反而在前端，当年历史原因这套系统选择了 angular 作为底层框架，进新人特别慢，上手 angular 确实需要两周的时间，现在国内几乎是 vue 的天下

@wqtacc 那承诺就是个笑话，在告诉懂的人，这甲方在质疑 restful 的安全性 ？？？

@iseki Websocket 这东西，一直没怎么用起来，看过有有人用 Websocket 写的 bbs 项目，各种原因也没推广开，没测过，但是有状态协议，对服务器的压力还是比无状态大的，说白了，普通的 web 应用的需求都是无状态的，任何绕开的方式，都是在对 http 造轮子

@fuxkcsdn 不觉得这是矫情，现场不就是不停的和甲方+友商小伙伴扯皮吗？都不加钱的甲方爸爸，只能算孙子~

@lesismal

认真看了#88 突然有种恍然大悟的感觉

web 其实提供了这么一套方案，叫 websocket 。只有一个方法 get ，初始化 token 通过 header 传输
然后，，，嗯，，，，[狂笑]
对比 http 那 9 种方法有诸多优势，及时性，有状态，可以发送 binaryType

@lesismal

> 抛开 RESTFul 不谈，我前面提到的三元 /三个维度的问题，其实 post delete 的方法在路由上就搞定了比如 /aaa/bbb/delete ，但是路由上做可以省去 Method 的不统一和比如这次聊到的 PUT 的问题

我们的理解可能不太相同

为什么要抛开 restful?至少我还没找到一种在 web api 设计中更优的最佳实践

你看了半天，也没找到你前面提的三元问题

至于说“省去 Method 的不统一”,其实你自己的举例中也在路由中，补入了一个 delete
难道我的
/user?ids=aaa,bbb
method delete
就没统一描述 /user 这个资源？

我在脑子里做了，想象中你的方案的落地，没找到比 restful 的优点

反而感觉像放弃了，http 协议做为应用层协议的优势，感觉上你在把 http 当 tcp 来玩

@lesismal 额，，，不会的，新项目我依然会坚持做这样的设计

考虑的点是基于这样几个考虑

1. 产品设计应该尽量统一，采用流行的模式，方便交付，以及和其他厂商同行对接，流行的规范，大多数人更容易接受，读到你是 delete 请求，自然知道这里是要删除一个什么东西，读到 post 的时候，知道这里是新增了一个什么东西，不是 and,create,built 一堆动词的滥用

2. 哪怕我改成全 POST 封装，实际还是会在 POST 的不管是 body 或者 url 中描述这个操作是 query ，还是 edit 或者 delete ，和写 header 里面的 method 头没区别，只是小聪明的重复造轮子了

3.不是每个客户都这么恼火，也有甲方，默认给关了，但是你提出需求，就直接放行了，不是每个客户都这么固执

4.这次坚持了，下一次同一个甲方再遇到这个问题，哪怕是其他同行就不存在沟通成本了

嗯，暂时想到这么多，突然想起两句话，其他地方不一定对，在这里我觉得可以参考“用户是需要被教育的”，“用户不会提前告知你什么是更好的”

我去，，，下班回来直接麻了，这破事儿居然吵热了

给各位汇报一下这个事儿的进展
最后的方案，是甲方也不想再花钱，我们写一个承诺书，我写了一句话，其他甩给商务去扩展了
------------------------------------
因为我司产品遵循 restful 设计原则导致的网络安全问题，由我方承担全部相关责任
------------------------------------
下午还有个小故事

最开始电话和网络中心主任沟通的，表示我们能说明是安全的就行，问题不大，
十分钟后又打电话来，说他问了他们专门管安全的专员，说这个就是风险！！！最后怎么变成修承诺说的就不知道商务怎么周旋的了


我前面已经说过了，这事儿其实也不是个什么事儿，

但是，我明明没有错，为什么要为别人的无知买单？要去“委曲求全”的“绕过”？

GET/POST+结构化 body ，省去了 method 设计这块的心智成本
-----------
这个看不先去了哈，那 http1.1 设计就太冗余了，按这个说法最安全的最好的浏览器发展方向，应该把包括 GET 在内的所有方法，都自动封装为一个 WANT 发送

各大厂商的开发 API 还搞什么 restful 呀，完全是莫名其妙的增加心智成本

有些想法很中肯，客户傻逼就不陪他玩，我绕过就行

但这次就是不太想绕过了，要么重新开发，要么你把 put 给放了

确实给了私钥的哈

不太认同那种因为甲方就要应承他的想法，什么都照甲方的想法改，最后出问题了还是会甩锅到自己头上。

就像十年前的项目，你不兼容 IE 就说你系统有问题，技术都顶着，技术栈全线更新全切 Chrome 了，现在客户也知道旧版 IE 不能正常显示不完全是系统的

就给了两个方案，要么双倍预算我们重做系统，要么防火墙放行

@liliclinton 真心老火
@unco020511 真的要吐了

@westoy 我们的也可以再 post 里面套用一个_model 参数来用 post 包装所有请求方式，外行也就不说，真不知道做防火墙那帮子人怎么想的

@xmumiffy 这波反向有道理，哈哈哈

@westoy 整改肯定是有方案，但是为什么要用别人的错，来增加自己的成本

http 的几个请求方法，就 header 字段有区别，要不是浏览器限制，get 也能承载 body 体，真的是有些防火墙厂商运维还四处宣扬，PUT 不安全，工作群里问他们不安全的点在哪里又说不出来

请问 planet 需要固定 ip 嘛？

@dreamramon 肯定用 bitwarden_rs 呀，自己部署自用

@lyhiving 那就难怪了，哎，太累了