googlepay 很明显就是我说的成功直接返回 object
上面哪個人說的不是返回 object，上面都是在討論返回的 object 是否需要包含成功代碼，還是說直接通過 http 的 200 表示成功。建議你話 1-2 分鐘看看上面針輪的話題和 LZ 的提問。

“业务请求成功 body 会有内容啊，为什么要区分网络请求成功，然后业务请求失败？你拿不到预期的内容那就是失败。
”
失敗時候的處理方式不一樣，
最簡單的例子，網絡失敗隔 10 分鐘重試，業務失敗檢查自身提交業務數據。如果業務失敗也是按網絡失敗處理，那你不就等於叫別人 ddos 你嗎？

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

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

“再者我供职的公司压根就没有面向中国市场的业务啊。”
那我沒什麼好說的了。

@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，國內現況不看看？
崇洋媚外 也要有個度，什麼樣的設計歸根到底不是應該要貼合市場業務嗎？

@h82258652 另外比較好奇，你們 nginx 都配置了 404 跳轉後全局錯誤頁後，返回都是 404 ？

@h82258652 你這樣，我感覺更混亂.....
另外，你帖子裡說的是：
“但我觉得首先这 code 肯定是多余的，可以直接从 http 状态码里面读取。”
那你失敗時候應該只有 http code 的 400,

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

那如果是請求成功(WEB HTTP 層的請求是正常的)，業務處理是失敗的(查無用戶)，
那這個時候請問你是通過 response 返回 404 嗎？
如果上了 CDN，設了 404 不死之身，那你的 code 最後不是又變成了 200 嗎？
又或者如 LS 所說，如果你被運營商劫持了，4XX 和 5XX 的他們都重定向去他們自家的廣告，那 code 不是變成了 200 嗎？

@h82258652 #157
那你這樣反而是脫褲子拉尿吧？

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

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


既然這樣你都想到了，那你還談什麼統一規格

@binux #153
按你說法，失敗時候就包一層 code 在 response 裡，成功的話就把 code 從 response 裡刪除嗎？
你這個說法，真的沒法接受哦。

結貼吧，
設計源於生活，生活回歸設計。

比方你去大保健。
點了個 688 的套餐。
工作人員給了你手牌 612
然後 JS 來上鐘，
打電話報鐘，
如果輸入手牌號，系統返回“450Hz，-10±3dBm0，0.35s on/0.35s off”忙音，證明線路忙，JS 可能會過一兩分鐘再試。
如果輸入手牌號，系統返回房間號，那麼 JS 只需要對一下房間號，看看有沒進錯房間即可。


如果 JS 輸入手牌號後，系統無論線路原因或輸錯手牌號碼原因，均返回忙音，
那 JS 太難了，
除了要鍛煉嘴，聽力也要鍛煉,

@uxstone #37 超市如果售賣管制刀具，那肯定要被追責，如果是售賣非管制刀具，但未進行實名制，那也會被追責。

不過參考華聲新聞對於實名制購買非管控刀具的標題，《“买菜刀实名制”纯属惰政之举》。
其實現在信產要求的，何嘗不是惰政之举

@MakeHui #141 你別這樣說啊，我是墻頭草哪邊有理哪邊倒。

畢竟一個人經驗和接觸到的知識面有點窄，所以理性的探討是支持的，沒任何敵意。
你說出來，哪怕是我覺得錯的，但另一層面上我不是又了解多一樣東西嗎....
當你說出來，我發現我是錯的，那我收穫更大了。

@lazyfighter
主要問題還是取決於監控粒度的大小。
如果監控內容只是需要成功或失敗,那複用 http code 的確簡單省事。
如果監控內容是需要區分請求成功率和業務執行成功率時，
明顯 http code 無法進行有效區分。

還有，在後端和後端的交互中，
如果遇到 5XX 的錯誤，基本會進行重發請求，
如果是遇到了 200 成功，response code 提示錯誤的，基本不會進行請求重發（具體看 code 的定義）。

@hantsy
所有的設計指南都是基於理想狀態進行描寫的。
全世界的業務都不是一成不變的，導致不同的公司就算處理相同的業務也存在不同的流程。
這個就類似於 社會主義 和 特色社會主義 的區別。
如果你真要什麼簡潔，那還不如直接逗號替換大法？

菩提本無樹明鏡亦非臺本來無一物何處惹塵埃

@Narcissu5 你既然知道熔斷是根據 http code 進行，那你怎麼還主張通過 http code 來代替 response 的 code 呢？
歸根到底就是兩套不一樣的 code，
非要把它們弄到一起，
項目小的話還沒影響，
項目大了的話不就搞到定義模糊嗎？

@Narcissu5 我明白你的意思，但是成本的高低是看業務的需求，
當業務是存在此方面的需求，成本就不會覺得高。
當業務對於這方面需求度不高，成本自然覺得高。

但是和你在上面說了三次 無法監控 ，
這真的是有點誤導啊。

你如果說在現有架構上增加監控，那的確如你所說，會消耗性能，並且業務量大的時候會對業務造成困擾。
但是建議你可以了解下旁路設備，增加旁路設備後對數據進行監控，就算業務量再大，頂多就是旁路設備處理存在延時，可監控報表維度一般都按小時 /天 /月 來統計，這點延時根本不足以影響數據準確度；而且旁路設備就算掛了，對業務一點影響都沒有。

另外交換機的端口鏡像，也是實現旁路的一個好設備。

@FS1P7dJz 坐標廣州，20M 鐵通線路，2M 電信 IPLC，2M 聯通 IPLC,cisco 3000 系列路由，跑了 10 多年，公司內部 120±10 台終端設備在使用，從未出過什麼事，也不存在什麼違規，包括家用寬帶，協議裡面沒有限制終端設備使用數量，業務經理還縫年過節跑上來送禮。

限制终端只能有 20 个。。
電信的終端限制 => 撥號次數
你路由夠強勁，帶多少台機電信根本不管，也無法管。

朋友网管建议拉网线（前期没预留，成本也不菲）
看完這句話，如果你連網線都沒有，那電信就算不限終端數，你那堆人怎麼上網呢？
還是其實你的終端數 是指電話線數量？

如果是電話線數量給個不負責任的方法你，4 芯電話線足矣上網，直接兩邊打網線頭，1326 線序即可。太長了的話你最好自己試試看會不會干擾。

另外電力貓，mesh 組網等，都是很好的選擇，推薦（ mesh>電力貓）

@Narcissu5 我看你說的，側重點在於監控方面吧？
我之前對結果其中一家數據交換公司，他們 PM 每月都會發送一份報表給我們，
其中包括 接口請求成功率，接口預定成功率
接口請求成功率 是他們考量他們自身服務的標準，其中包含簽約時候的 sla。
接口預定成功率 這個是考量他們系統和酒店系統的服務標準。
實際上除了這兩份報表外，還有其餘很多報表，大致是分析推送數據成功率，延遲等等。

你說 response 返回多一層 code 無法監控，
那請問別人為何又能監控，而你無法監控？

@chendy http 的 code 只能代表請求的結果吧？
返回數據裡的 code 是代表業務的執行結果，根本是兩回事，
不要動不動就說別人不懂 http 的 code，只是別人想的比你多一步。

eg：
在線預訂門票的栗子，
對方業務系統規定：
當 code 為 9999 時，代表對方系統維護中，所有請求 30 分鐘後重試。
當 code 為 1XXX 時，違反門票業務約定（ XXX3 位數代表著不同的約定）
當 code 為 2000 時，代表著訂單提交成功
當 code 為 3XXX 時，代表處理失敗，違反直連約定，具體根據 XXX3 位代表不同的結果，有可能是重複單號

直連約定上，當 http 服務不可用（返回非 200，需要每隔 5 分鐘進行重試，超出 10 次後線下聯繫處理。）
當返回 9999 時，代表對方系統維護
兩個是不一樣的概念，你為何可以那麼優秀地認為別人是多此一舉呢？如果你用 http 的狀態碼來表示，拍錯的時候不會導致連業務信息處理出錯或 http 請求出錯都區分不了嗎？

另外“类似的道理，还有用参数指定返回格式的人，大概是不知道 Accept 头（可能也不知道 Content-Type”
給個例子你，
甲方對接了很多套酒店系統，有些系統返回的是 xml，有些返回的是 json。
然後乙方和甲方對接，數據返回根據甲方提供的 api 均為 json，
但是由於很多實時請求是乙方 發送請求給甲方 甲方 再發給酒店，（等於甲方做數據交換），
這個時候甲方在返回給乙方的數據架構上，加上數據具體格式，有問題嗎？
response->{
code:2000,
type:'json',
data:'{code:xxxxx,data:xxxxxxxxxxxxxxx}'
}
你肯定會說為什麼甲方不解釋了酒店數據，然後直接返回給乙方。
那是因為甲方是做數據交換服務，在數據改動最少的範圍內傳遞給乙方。

我看過很多涉黃行業，由於地址長被封，所以把地址丟去 github，甚至利用 gitpage 做個宣傳。
不過說真的，最討厭的就是一堆不懂技術的政治人管理著技術的事情。

@alexwu
硬件層基本實時。
應用層數據差異時間要看自身業務可接受丟失比例進行配。
備份密度越高，存儲代價越大
備份密度越低，丟失風險越大

底層的基本靠運營商的系統架構進行。
應用層的基本運營商有額外服務提供。