過去幾個(gè)月里，我一直在對(duì)付一個(gè)流行健身品牌的 API，最后發(fā)現(xiàn)自己陷入了一種卡夫卡式的噩夢。程序員都喜歡挑戰(zhàn)，優(yōu)秀的程序員一定要征服種種挑戰(zhàn)。我一直覺得自己是一個(gè)非常優(yōu)秀的程序員。因此，盡管每天晚上我都以失敗告終，只能上床睡覺，但我內(nèi)心深處的某些東西是不會(huì)讓我就此放棄的——第二天早上，我會(huì)帶著新的想法和新的動(dòng)力滿血復(fù)活。
這樣的循環(huán)已經(jīng)持續(xù)幾個(gè)月，這就像一場夢，日復(fù)一日，遲遲沒有蘇醒的一刻。我要處理的任務(wù)很簡單：獲取數(shù)據(jù)，保存數(shù)據(jù)，完事。但面對(duì)這個(gè) API，我被一堆脆弱的代碼團(tuán)團(tuán)圍住，追逐著那些我永遠(yuǎn)都抓不到的錯(cuò)誤。
那么，怎樣才能構(gòu)建一個(gè)具備如此高技術(shù)障礙的 API，讓你可以擊敗一個(gè)擁有 20 年經(jīng)驗(yàn)，過去總有辦法走出困境的老手呢？你如何讓他慢慢抓狂，并讓他從自己所熱愛的這一職業(yè)中獲得的所有快樂一掃而空呢。好吧，我會(huì)告訴你訣竅的。
我們先來布置角斗場地。
對(duì)于授權(quán)需求，我們將使用 OAuth1a。當(dāng)然，這是一個(gè)非常好的標(biāo)準(zhǔn)，但用它簽署請(qǐng)求會(huì)增加那么一點(diǎn)點(diǎn)復(fù)雜性，讓你永遠(yuǎn)沒法搞清楚原來是簽署導(dǎo)致請(qǐng)求失敗的。
服務(wù)器到服務(wù)器的通信
我們不會(huì)響應(yīng)你的 API 請(qǐng)求，而是給你回電。你請(qǐng)求服務(wù)器提供一些數(shù)據(jù)，然后在從現(xiàn)在到宇宙終結(jié)之前（或永遠(yuǎn)不會(huì)）的某個(gè)時(shí)間點(diǎn)上，我們會(huì)做出回應(yīng)。響應(yīng)一般需要幾毫秒，但有時(shí)需要幾分鐘，在極少數(shù)情況下需要幾個(gè)小時(shí)。但最重要的是，如果我們沒有任何數(shù)據(jù)，我們根本就不會(huì)做出響應(yīng)。不一致是程序員的天敵。
這種設(shè)置在實(shí)踐中意味著什么呢？這意味著你需要在服務(wù)器或代理后面設(shè)置一個(gè)端點(diǎn)。這也意味著在你的單元測試中，如果沒有響應(yīng)，那么你將不得不做一些工作。你得編寫一些代碼，對(duì)其進(jìn)行測試，如果失敗還要檢查你的 web 服務(wù)器日志。
但是，也許在你查看請(qǐng)求通過的那些日志時(shí)，它終于有反應(yīng)了，只不過響應(yīng)來得慢一些。不過當(dāng)然 JSON 沒有按照你預(yù)期的方式格式化，所以請(qǐng)重來一遍吧。
禁止重復(fù)數(shù)據(jù)
這招可是很不錯(cuò)的。不管你請(qǐng)求任何數(shù)據(jù)，你都只能請(qǐng)求恰好一次。不是一分鐘一次，也不是一小時(shí)或一天一次——是這輩子都只能請(qǐng)求那么一次。這實(shí)際上意味著任何單元測試都是不可重復(fù)的，想要重來一次？請(qǐng)手動(dòng)注冊(cè)新帳戶并在里面人工填好數(shù)據(jù)。
假設(shè)當(dāng)代碼生效時(shí)，一位用戶請(qǐng)求了某個(gè)時(shí)間段內(nèi)的數(shù)據(jù)，他要的數(shù)據(jù)可能存在也可能不存在，你可能會(huì)，也可能不會(huì)收到這些數(shù)據(jù)，但你仍然需要跟蹤這一請(qǐng)求，因?yàn)槿绻氵@個(gè)請(qǐng)求只重疊了那么區(qū)區(qū)一天，那么在將來某個(gè)時(shí)候，你就會(huì)收到一條錯(cuò)誤消息。當(dāng)生產(chǎn)環(huán)境中的請(qǐng)求失敗時(shí)會(huì)發(fā)生什么呢？當(dāng)然沒有緩解措施，你什么都做不了。這些數(shù)據(jù)是不可恢復(fù)的——永遠(yuǎn)別指望它能恢復(fù)了。
我可以用一整天談?wù)撨@個(gè)技巧的強(qiáng)大力量。不過你只要簡單地想象一下，比如你編寫了自己的第一行代碼，然后又成功地執(zhí)行了它，然后當(dāng)你再次運(yùn)行它時(shí)，它就沒有任何反應(yīng)了。想象一下項(xiàng)目的其他部分全變成了這個(gè)樣子，那會(huì)是多么壯觀的場面。
開發(fā)和 QA 速率限制
我想你可能會(huì)爭辯說，將 QA 速率限制設(shè)置為遠(yuǎn)低于生產(chǎn)環(huán)境的速率可能是有原因的。但如果將閾值設(shè)置為每分鐘 100 天的數(shù)據(jù)（不是請(qǐng)求）會(huì)有什么樣的結(jié)果呢？這個(gè)技巧特別狡猾。
首先，它的確為你的開發(fā)測試周期設(shè)置了一個(gè)最大閾值。你可以寫一些代碼，運(yùn)行一個(gè)測試，然后開始等待。但它的要點(diǎn)在于它加入了另一個(gè)因素，讓代碼可能會(huì)莫名其妙地失敗。
最厲害的是當(dāng)你正在嘗試開發(fā)一個(gè)高度可擴(kuò)展的應(yīng)用程序的時(shí)候，你到底該怎么開始測試隨便什么類型的負(fù)載呢？簡單的答案是你可以在生產(chǎn)環(huán)境中進(jìn)行測試，也可以根本不做任何測試。
PROD 中的應(yīng)用程序級(jí)別速率限制
應(yīng)用程序級(jí)速率限制這個(gè)技巧的美妙之處在于，你需要一個(gè)消息隊(duì)列才行。當(dāng)然可能還有其他技巧，但如果它是一個(gè) Web 應(yīng)用，并且你不想讓一堆長時(shí)間運(yùn)行的線程在隊(duì)列中運(yùn)行，那么這幾乎是你唯一的選擇。
當(dāng)然，它們也加入了其他一些東西，但這些幾乎不值得一提，因?yàn)檫@些東西只不過是典型的數(shù)據(jù)結(jié)構(gòu)挑戰(zhàn)或糟糕的參數(shù)化選項(xiàng)而已。這些是你平日里經(jīng)常要面對(duì)的挑戰(zhàn)，并不是那些即便是最有經(jīng)驗(yàn)的開發(fā)人員也會(huì)屈服的挑戰(zhàn)。
在過去的幾個(gè)月里，我花了很多時(shí)間試圖想象這個(gè) API 背后的團(tuán)隊(duì)究竟是什么樣子的，以及他們到底有什么樣的動(dòng)機(jī)來開發(fā)這樣一個(gè) API。無論你是如何看待它的，他們的初衷肯定是防止別人使用這個(gè) API。也許，他們正在與一個(gè)其基礎(chǔ)設(shè)施擁有數(shù)十年歷史的系統(tǒng)交互，這一系統(tǒng)會(huì)因最輕微的干擾而崩潰。也許他們有很多新招來的開發(fā)人員，編寫了一些非常低效的代碼，而當(dāng)他們探討解決方案的時(shí)候，最后想出來的辦法就是盡可能給用戶設(shè)置更多障礙？或者也許他們只是絲毫沒有同理心。也許當(dāng)他們權(quán)衡設(shè)計(jì)決策時(shí)，可用性這一條的評(píng)分被減到了零，這樣其他所有問題就都能得到最大程度的重視了。
但我認(rèn)為還有另一種可能。公司都喜歡把他們的花園圍起來，但在健身領(lǐng)域，數(shù)據(jù)可移植性是一個(gè)賣點(diǎn)。那么，你如何才能同時(shí)實(shí)現(xiàn)兩者呢？你如何才能一邊把你的花園圈起來，與此同時(shí)給大家指出大門的位置呢？如果是因?yàn)檫@樣的理由，這個(gè)開發(fā)噩夢就完全可以解釋清楚了。在這種情況下，認(rèn)真努力地嘗試編寫代碼來使用它的用戶就是唯一的傻瓜。
原文鏈接：
https://chrislukic.com/2021/06/16/techniques-to-prevent-adoption-of-your-api/
