深度技術文章，第一時間送達！

作者 | Jennifer Riggins

翻譯 | Vincent

API已經成為了我們生活中很常見的一部分，那麼在API設計過程中有哪些容易犯的錯誤呢？作者在本文介紹了三種，也給出了相應的解決方案，不妨一起來看一下吧！以下為譯文。

作為表單工具Typeform的API領頭人，Jason Harmon恰好也與JSON schema同名了，他最近就「哪些因素破壞了生產環境」這個問題在APIdays會議上做了非常積極的討論。事實上有三個因素。

API解決方案＃1：如何讓HTTP POST代替GET

由於人們更喜歡使用HTTP GET進行數據檢索，因此這就使得HTTP POST變得並不是那麼常見了。雖然使用GET會導致URL變得很長，但是由於它們與大多數查詢沒有什麼不同，因此GET已經成為使用HTTP構建過濾查詢的默認方法了。（同樣值得注意的是，較長的網址往往更容易被Google發現，所以它們對搜索引擎的優化很有幫助。）

但是由於Web應用程序需要使用瀏覽器，因此使用GET很有可能會出現問題。根據Harmon的說法，由於瀏覽器（特別是Chrome）特別容易出現緩存，因此如果出現了一個看似重複的GET請求，那麼可能會出現一次請求出現兩個著陸頁。在Typeform上面，Harmonform和他的團隊發現由於已經被瀏覽器標記為重複，實際上頁面已經轉儲過了。

為了解決這個問題，Harmon建議把GET改為POST，因為在HTTP規範中，POST是不會緩存的。

如果請求的API已經在緩存里了，而你又不知道為什麼它會在緩存裡面，Harmon建議可以從GET入手查找原因：

1. 儘可能添加POST（請記住，從GET更改為POST可能會導致API合同發生重大更改）

2. 將?cache_buster=添加到GET（作為維護合同現狀的一種方式，如果在開發人員社區中進行重大更改將會非常困難）

這些措施可以有效控制緩存。

API解決方案#2：如何壓縮多次輪詢的API

像Web應用程序這樣的API消費者們一次又一次地調用某個API時，這就被稱為輪詢API。這種情況通常發生在API消費者期望定期更改某些數據，並得到最新數據時。例如，在Typeform的某些情況下，集成表單的消費者可以定期輪詢API，以便獲得表單的結果。API消費者可能會使用Zapier，如果平均每5分鐘調用一次，那麼網路上面會顯示大量的調用。

針對這個問題，Harmon提出了這些疑問：

數據集很大嗎?

查詢的代價高嗎?

數據經常變化嗎?

客戶端多嗎?

「我們也提出了一個快速的解決方案，就是設置webhooks，它是一種反向的API。不是他們主動發起請求，而是當某些事情出現以後，我們主動給他們發送POST，」Harmon說。

他把這種請求之間的差異描述為戲劇性的。

「作為webhooks的客戶，整個晚上我只想調用一次API，」Harmon說，為了確保不會錯過webhook的交付。他接著說，webhook並不是獨立存在的，它與API可以很好地兼容，因為它們減少了所需調用的次數。

除了webhook，他還提供了其他選項：

緩存(但是很難實現)

資料庫只讀許可權的鏡像

API解決方案#3：如何使用群組調用來利用普通的調用鏈

每次構建API時，並不是都需要對所有的東西都進行更新，Harmon以Typeform表單的微服務結構化版本為例說明了這一個問題。在Typeform的某些情況下，立即更新所有內容需要7個單獨的API調用，這將導致性能瓶頸。現在正在考慮的一種解決方案是將REST用於graphql驅動的方法。與此同時，Harmon說他們開發了以下的替代方法。

正如上面的圖片中看到的，團隊將表單分解為一個類似於微服務的結構體，該結構體將某些常見的鏈式後端活動綁定在一起，以便更有效地服務前端。在響應調用時，伺服器端JavaScript (Node.js)中的某一層將處理業務流程，從而形成一個面向前端的(BFF)。這是一種將僵化資源結構轉化為優勢的方法。

像許多其他情況一樣，這種情況關鍵是要考慮客戶端如何執行調用，以及如何使用該工具。Typeform的團隊識別了上面看到的模式，他們可以將調用集中到單個鏈中，比如Form > Design > Background > Image。Harmon說，要關注他所說的N+1調用，比如當客戶端可以調用父類時，但是實際上調用了相關條目或者子條目。如果能夠識別這樣的行為模式，那麼就可能會減少API調用的數量，從而提高性能。

Harmon還提到了BFF這種微服務結構體使得新增動作在實時場景中變得容易。不過，他也提出了警告，這是需要提前讓用戶體驗設計師參與進來

站在用戶的角度構建API

「構建API時，首先需要考慮的應該是用戶應該如何使用。我們稱之為API設計，但我們的思考方式更傾向於工程師。「試著跟將要使用API的人產生一些同理心。當真正做到這一點的時候，問題總是可以提前被發現。」

對於開發人員來說這一點很關鍵，因為這不僅意味著你的客戶會繼續使用你的API，而且你不活問題和解決問題的能力也會增強，這樣才會構建出用戶實際上想要使用的產品。

Harmon繼續說，這個過程不僅僅是傾聽客戶，而是要確保在滿足客戶所有的需求以後，API還能是強大的、安全的和靈活的。

Harmon強調，API設計不僅僅是項目開始時的規範。它也可以解決一些很嚴重的問題，包括他上面分享的那些「廉價的修復」。所有這些修正首先基於邏輯。

「想想看，在這些電話發生後，會發生什麼事情。你怎麼讀它在你的日誌里寫的故事?」Harmon問道。

就像所有優秀的客戶服務和用戶體驗創造一樣，開發人員的體驗可以歸結為兩件事——傾聽你的API消費者是什麼，而不是說什麼，然後用邏輯來解決他們最大的問題。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！