經過壹個下午長時間的狂想之後，妳最終敗下陣來，並看到Amazon是如何保持API請求安全的。妳不清楚為什麽，但讀完整頁關於如何為Amazon網絡服務裝配壹個請求後，妳依然覺得不完全合理。這個“簽名”和什麽連在壹起？代碼示例中的“data”參數是什麽？這樣，妳會繼續查找關於“安全API設計”的文章……
當遇到其他人問同樣的問題時，妳看到壹些指出“HMAC”或其他事物的優秀回復，但還是不太確定。
妳找到其他鼓勵妳使用“HMAC”的文章並且妳正H-FINE地使用它，如果有人將“HMAC”解釋成簡明的H_ENGLISH的話。
妳的確偶遇了壹個有道理的蒸餾的基本概念，它是這樣壹簡明的英語描述的：
壹個服務器和客戶端知道壹個公鑰和壹個私鑰；只有服務器和客戶端知道私鑰，但每個人都知道公鑰……但不關心別人所知道的。
壹個客戶端生成壹個唯壹的HMAC（哈希）表示它到服務器的請求。通過把請求數據（參數和值或XML/JSON或任何它計劃發送的數據）以及請求數據的散列blob和私鑰結合來實現。
客戶端隨後將這個HASH以及所有它將要發送的參數和值壹並發給服務器。
服務器接到請求，並使用與客戶端相同的方式重新生成自己獨有的基於提交值的HMAC（哈希）。
然後，服務器比較這兩個HMAC，如果相同，服務器就信任這個客戶端並執行請求。
這似乎很直截了當。最初讓妳困惑的是，妳以為原始請求是經過加密傳送的，但實際上，HMAC方法所做的壹切只是使用只有客戶端和服務器才知道的私鑰將參數生成為壹些獨特的校驗和（哈希）。
隨後，客戶端將這個校驗和及原始參數和值發給服務器，然後服務器復核校驗和（哈希）以確定它接受客戶端所發的請求。
因為根據假設，只有在客戶端和服務器知道私鑰，我們假設如果他們的哈希匹配，那麽它們會互相信任，以至服務器隨即正常處理這個請求。
妳知道在現實中，這就相當於某人過來對妳說：“Jimmy讓我告訴妳把錢給Johnny”，但妳不知道這個人是誰，所以妳要伸出手去試探他，看看他是否知道這個秘密握手。