方法一
要求請求端帶上一個隨機字符串state（也可以是特定規則生成的，甚至是從服務器上請求過來的），服務端（用過濾/攔截器之類的實現不會影響業務代碼）收到之后緩存一定的時間（長短視業務和硬件），每次請求都檢查state值是否在緩存中存在（或者是否符合規則，或者是否由服務器生成），如果存在拋棄或者給出特別的響應，第一個被接受的請求就按照正常處理。
需要注意的是，判斷並緩存這是要一個原子操作。
方法二
請求頭里帶用戶username和password，到服務器端做驗證，通過才繼續下邊業務邏輯。
有點：防止了服務器端api被隨意調用。
缺點：每次都交互用戶名和密碼，交互量大，且密碼明文傳輸不安全。
方法三
第一次請求，要求username和password，驗證通過，種cookie到客戶端，app保存cookie值。
每次請求帶上cookie。
點評：和pc上瀏覽器認證的原理一樣了。
方法四
制定一個token生成規則，按某些服務器端和客戶端都擁有的共同屬性生成一個隨機串，客戶端生成這個串，服務器收到請求也校驗這個串。
缺點：隨機串生成規則要保密。
比如:一個使用PHP框架的工程，框架每次交互都會有 module和action兩個參數做路由，這樣的話，我就可以用下邊這個規則來生成token
app要請求用戶列表，api是“index.php?module=user&action=list”
app生成token = md5sum ('user'.'2012-11-28'.'#$@%!'.list) = 880fed4ca2aabd20ae9a5dd774711de2;
實際發起請求為 “index.php?module=user&action=list&token=880fed4ca2aabd20ae9a5dd774711de2”
服務器端接到請求用同樣方法計算token