V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  markgor  ›  全部回复第 35 页 / 共 44 页
回复总数  862
1 ... 27  28  29  30  31  32  33  34  35  36 ... 44  
2019-10-24 08:51:16 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@Woood 騰訊我不好說,畢竟吃人嘴軟拿人手短;反正我也不接觸騰訊遊戲,就微信和 QQ 這兩方面,我覺得還算好吧。唯一貢獻給騰訊的只有綠磚和 qq 會員了。不過騰訊雲,有點坑。
2019-10-23 14:02:49 +08:00
回复了 18510047382 创建的主题 JavaScript JavaScript 虚拟键盘 A-Keyboard.
民生的鍵盤:打亂字符排序
中信、建設、招商:不打亂排序
提交傳輸的時候估計是密文。

不過可以的話,做個可選配置,後端生成密文,前端渲染,隨機排序,提交密文,服務端再解。-----------隨便想的,可能有很多出入問題.....
2019-10-23 13:59:30 +08:00
回复了 18510047382 创建的主题 JavaScript JavaScript 虚拟键盘 A-Keyboard.
Default、Dark 比較好看
考慮下做成類似網銀那種安全鍵盤估計更好。
2019-10-23 13:39:08 +08:00
回复了 lepchaos 创建的主题 程序员 新手询问,关于堡垒机与目标机的转发问题
@th00000 你這個叫跳板機吧....
我接觸過大多數堡壘機都是通過 web 形式登錄,然後選擇需要連接的資產進行遠程操作。
堡壘機主要做資產記錄,還有避免賬號密碼外洩出去,最重要的就是日誌審查。
@eason1874 #29
我試過的 1M 機器不走 CDN 情況下和 2L 所說的一樣。
不過可能你把所有資源打包一起 50KB 的原因吧。(這個真厲害,我這 JS 那堆文件加起來就不止了,上別人的 cdn 怕不穩定)
另外好奇你那站點一張圖片都沒有嘛?還是都丟 CDN 去了?
@eason1874 HTML 不就是靜態嗎...?
2019-10-23 09:21:21 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@binux 剛又看了一次,是我看錯了,裡面的確是寫通過 response 來傳遞 http code。
2019-10-23 09:18:19 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@binux
強扳貼臉就沒意思了,
你自己去看清楚再來噴吧,
人家說這模式下 http code 永遠返回 200。所以在 response 裡包個 code。
你非要強行說包這個 code 是 http code 那我也沒辦法。
就好像上面所說的,其實你也可以繼續貼臉啊,
你可以說人家成功的包裹的都是 http code,而不是業務 code 啊。
剛以為自己看錯了,
以為你說的是 1M+CDN 滿足需求。
但是看看標題,你說的是為 1M 正名。
你可以試試不上 CDN 的時候情況如果,上了 CDN 為 1M 正名這不有點扯嗎....
你的 1M 只是回源帶寬 1M,別人訪問有緩存走緩存,沒緩存去 CDN,非靜態資源跑會源站。
但是你上面又說了都是靜態資源,那不就等於除了第一次訪問 CDN 需要回源,後續的 CDN 基本不會回源嗎?
1M + CDN = 15 万 PV
20M = 15 万 PV
LZ 的意思是 20M = 1M 嗎?
2019-10-23 09:00:38 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@binux #236 請看清楚在回復。
@cassyfar 建議你看看上面的回復再來說主流的這個問題吧。
2019-10-22 15:54:19 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@binux #1 的剛去看了
其中有一段指出“
There are 2 situations where an envelope is really needed - if the API needs to support cross domain requests over JSONP or if the client is incapable of working with HTTP headers.

JSONP requests come with an additional query parameter (usually named callback or jsonp) representing the name of the callback function. If this parameter is present, the API should switch to a full envelope mode where it always responds with a 200 HTTP status code and passes the real status code in the JSON payload. Any additional HTTP headers that would have been passed alongside the response should be mapped to JSON fields, like so:

兩種特殊情況會使用到 code。JSONP 和無法獲取 header 的情況下,
如果你原生就不支持攜帶業務 code,那遇到前端跨域 jsonp 請求時,你再作處理?
2019-10-22 15:14:00 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@binux
你意思是說,無論成功還是失敗,http code 都是返回 200 ?
看看上面討論的內容,說的是錯誤碼複用 http code。既然是複用了,談何都返回 200 看 response ?

然後你參考 #209 的回復,你們都是女裝大佬,應該容易接受吧。

最後,我承認 Google 和 IBM 的偉大和技術,但這不意味著我看不起 AT。
除了百度&360 一切巨人都值得尊重。
2019-10-22 14:53:50 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@binux 忘記 @你了,不好意思
googlepay 很明显就是我说的成功直接返回 object
上面哪個人說的不是返回 object,上面都是在討論返回的 object 是否需要包含成功代碼,還是說直接通過 http 的 200 表示成功。建議你話 1-2 分鐘看看上面針輪的話題和 LZ 的提問。

“业务请求成功 body 会有内容啊,为什么要区分网络请求成功,然后业务请求失败?你拿不到预期的内容那就是失败。

失敗時候的處理方式不一樣,
最簡單的例子,網絡失敗隔 10 分鐘重試,業務失敗檢查自身提交業務數據。如果業務失敗也是按網絡失敗處理,那你不就等於叫別人 ddos 你嗎?

“失败就去解析失败 object 就好了啊,你自己的例子已经给你示范了,你无法理解吗?”
建議你話 1-2 分鐘看看上面針輪的話題和 LZ 的提問。

“bat 自己连个全站 HTTPS 都做不到,他们的规范你还要去学?”
總有人覺得自己比 bat 都厲害,但卻幹不掉 bat。

“再者我供职的公司压根就没有面向中国市场的业务啊。”
那我沒什麼好說的了。
2019-10-22 14:46:23 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
googlepay 很明显就是我说的成功直接返回 object
上面哪個人說的不是返回 object,上面都是在討論返回的 object 是否需要包含成功代碼,還是說直接通過 http 的 200 表示成功。建議你話 1-2 分鐘看看上面針輪的話題和 LZ 的提問。

“业务请求成功 body 会有内容啊,为什么要区分网络请求成功,然后业务请求失败?你拿不到预期的内容那就是失败。

失敗時候的處理方式不一樣,
最簡單的例子,網絡失敗隔 10 分鐘重試,業務失敗檢查自身提交業務數據。如果業務失敗也是按網絡失敗處理,那你不就等於叫別人 ddos 你嗎?

“失败就去解析失败 object 就好了啊,你自己的例子已经给你示范了,你无法理解吗?”
建議你話 1-2 分鐘看看上面針輪的話題和 LZ 的提問。

“bat 自己连个全站 HTTPS 都做不到,他们的规范你还要去学?”
總有人覺得自己比 bat 都厲害,但卻幹不掉 bat。

“再者我供职的公司压根就没有面向中国市场的业务啊。”
那我沒什麼好說的了。
2019-10-22 14:28:37 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@binux
https://developers.google.cn/pay/api/web/reference/response-objects#example_6
要不你看看 googlepay api ?
google 某些接口成功不會返回,但某些接口成功會返回,這你又怎麼看?

没有 code 你就不会判断成功了吗?
可以判斷成功啊,但你怎麼區分網絡請求成功和業務請求成功?
哦,對了,你肯定又要繞回去題主說的是成功而不是失敗。
但是你可以也看清楚下,題主後面的字句嗎?
"但后面有自己项目的话,还是想弄标准一点。不知道一般来说,大家是怎样实现?"
你覺得實際項目中真有只需要考慮成功而不需要考慮失敗的設計嗎?


另外我不明白,你是有多少項目對接的 google,github,twitter ?還是你的項目全都是對接這些?
如果你平時實際對接的“第三方”比較多,你就自然明白為什麼那麼多人說要包多個 code。


另外,阿里,騰訊,百度這三家 bat 也是進不了你法眼吧?怎麼你舉例只是 google,github,twitter,國內現況不看看?
崇洋媚外 也要有個度,什麼樣的設計歸根到底不是應該要貼合市場業務嗎?
2019-10-22 13:04:20 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@h82258652 另外比較好奇,你們 nginx 都配置了 404 跳轉後全局錯誤頁後,返回都是 404 ?
2019-10-22 13:01:28 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@h82258652 你這樣,我感覺更混亂.....
另外,你帖子裡說的是:
“但我觉得首先这 code 肯定是多余的,可以直接从 http 状态码里面读取。”
那你失敗時候應該只有 http code 的 400,

然後成功的時候,連 code 都沒有了,等於每個接口都要重複定義一個標準。

那如果是請求成功(WEB HTTP 層的請求是正常的),業務處理是失敗的(查無用戶),
那這個時候請問你是通過 response 返回 404 嗎?
如果上了 CDN,設了 404 不死之身,那你的 code 最後不是又變成了 200 嗎?
又或者如 LS 所說,如果你被運營商劫持了,4XX 和 5XX 的他們都重定向去他們自家的廣告,那 code 不是變成了 200 嗎?
2019-10-22 12:52:44 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@h82258652 #157
那你這樣反而是脫褲子拉尿吧?

失敗的話數據架構是包成這樣的:
{
code:xxx
msg:'xxxx',
data:'xxxxxx'
}

然後成功的時候,把 code 抽走,變成這樣了:
{
msg:'xxxx'
data:'xxxx'
}


既然這樣你都想到了,那你還談什麼統一規格
2019-10-22 12:50:01 +08:00
回复了 h82258652 创建的主题 程序员 采取 RESTful 风格的 api 是否应该对结果包一层?
@binux #153
按你說法,失敗時候就包一層 code 在 response 裡,成功的話就把 code 從 response 裡刪除嗎?
你這個說法,真的沒法接受哦。
1 ... 27  28  29  30  31  32  33  34  35  36 ... 44  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2854 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 21ms · UTC 11:52 · PVG 19:52 · LAX 04:52 · JFK 07:52
Developed with CodeLauncher
♥ Do have faith in what you're doing.