**的前後端通訊，往往會有非同步請求，這時應該怎麼設計 api？
我最近讀到一篇文章，作者介紹了他的做法，設計得很精細，我覺得值得借鑑，可以當作非同步 api 的標準設計。
為了便於比較，先看看同步 api 的設計。下面是乙個很簡單的例子。
客戶端發出乙個請求，要求建立資源。
伺服器回應 201。postname='death star'
201 created告訴客戶端，請求成功，資源已經建立。新的資源的**請看location字段。
如果伺服器不能立即返回結果，就形成了非同步操作。
客戶端的請求還是一樣的。
伺服器回應 202。postname='death star'
202 accepted告訴客戶端，請求已經接受，但還沒有處理，可以去location字段查詢進展。
除了上面的頭資訊，伺服器的回應如果有資料體，可以返回一些有效資訊（比如任務完成的估計時間、當前狀態等等）。
過了一段時間，客戶端就發出請求，查詢非同步處理的進展。
伺服器回應 200。get
200 ok告訴客戶端，請求成功，具體情況檢視資料體。資料體裡給出提示，非同步操作已成功或還需要等待。
有一種特殊情況，使用者查詢非同步操作的進展的時候，可能會希望，如果非同步操作已經完成，就直接跳轉到新資源。
這時，伺服器回應 303。
303 see other告訴客戶端，重定向到不同的資源。location字段就是跳轉的目標，也就是新資源的**。
一旦非同步操作完成，客戶端可以要求伺服器刪除查詢鏈結。
伺服器回應 204。delete
http/1.1 204 no content
204 no content告訴客戶端，刪除成功。以後，客戶端再訪問這個查詢鏈結，伺服器回應404 not found。
如果客戶端不刪除查詢鏈結，伺服器完成非同步任務後，也可以自動刪除。客戶端再請求這個鏈結，伺服器回應410 gone，表示該鏈結永久性不再可用。
（完）
Node教程 非同步API
導學 通過返回值拿結果 path.join 通過函式拿結果,fs.redfile 在node中有兩種api 同步的api還有非同步的api 同步所謂的同步就是一步一步的走 非同步當前的api不會堵塞後續的 的執行 對比不能通過返回值拿結果 這裡舉例說明 讀取檔案的操作是非同步的 fs.readfil...
api 設計良好 API 的特點
這裡 的 api 均為系統邊界的api設計，而對於內部 api 來說不在 範圍之內。變動困難 api 就像乙個人一樣，我們和乙個api打交道的時候需要了解這個人的特性偏好等，有的人很好相處，而有的人讓人很頭疼，尤其是你不得不和他打交道的時候。和人一樣，如果你不得不和他打交道，要改變他的秉性是很痛苦的...
服務API設計 之 API設計原則
對接xx業務時，xx業務具備的功能和api全靠跑業務負責人那反覆逐個詢問 確認。用哪個api 怎麼用 有沒有限制 等等 各個業務間，甚至同一業務內，api風格不統一。xx業務api效能方面未知。隨著業務的演進，開放的api持續在增加，但類同的很多 api編碼規範迫在眉睫 自解釋 易學習 易使用 難誤...