『壹』 在rest介面規范中，post成功創建一個新的資源後，伺服器應該返回狀態碼是多少
2xx
200 OK
所有人都知道 200 OK 是什麼。這估計是最經常被濫用的狀態碼。很多人在應該使用其它 2xx 狀態碼時都選用了 200 OK 來表示。
201 Created
如果你在設計一個 REST API，或者一個 CRUD API，當你使用 POST（或者 PUT）成功創建一個新的資源後，伺服器應該返回 201 Created 同時在 header 的 Location 欄位給出剛剛創建好的這個資源的 URI。
例如說，如果你使用 POST 請求通過 \comments URI 創建了一個新的評論，那麼伺服器應該返回 201 Created，同時帶上形如Location: \comments\1234 的欄位表明新創建的評論的 URI。
202 Accepted
如果伺服器在接受請求後，需要進行一個非同步處理才能有結果，並且覺得不需要讓 TCP 連接保持到結果出來再返回，它可以返回 202 Accepted，意思是請求已接受，但沒有立即可返回的結果。
204 No Content
在一個 REST API 或者 CRUD API 裡面，當你使用 PUT 成功更新一個資源後，如果伺服器完整接受了客戶端的更新，沒有拒絕也沒有額外更新，那實際上是不需要返回任何東西的，因為現在客戶端和伺服器端已經擁有完全一致的狀態。在這種情況下，伺服器可以返回 204 No Content，同時 body 為空，客戶端就知道它的狀態已經跟伺服器端同步了。
206 Partial Content
斷點續傳和多線程下載都是通過 206 Partial Content 實現的。
請求的 header 必須包含一個 Range 欄位，表明自己請求第幾個位元組到第幾個位元組的內容。如果伺服器支持的話，就返回 206 Partial Content，然後使用 header 的 Content-Range 指明範圍，並在 body 內提供這個范圍內的數據。
3xx
301 Moved Permanently
永久性重定向。目標由 header 的 Location 欄位給出，同時 body 中也應該有指向目標的鏈接。新請求使用的方法應該和原請求的一致。如果用戶使用 HEAD 和 GET 以外的方式發起原請求，客戶端在遇到 301 Moved Permanently 後應當詢問用戶是否對新的 URI 發起新請求。
302 Found
臨時性重定向。
這應該是瀏覽器實現最不符合標準的一個狀態碼了。理論上，除了臨時性這一點，302 Found 跟 301 Moved Permanently 應該是完全一樣的。然而實質上，很多瀏覽器在遇到 302 Found 後就會使用 GET 去請求新的 URI，而無論原請求使用的是何種方法。由於這種現象的普遍存在，使得這成為了一個與書面標准相違背的事實標准，新的客戶端在實現時很難選擇應該遵守哪一個標准，所以 RFC 2616 專門新增了 303 See Other 和 307 Temporary Redirect 兩個狀態碼來消除二義性。
303 See Other
臨時性重定向，且總是使用 GET 請求新的 URI。
304 Not Modified
如果客戶端發起了一個「條件 GET」，同時資源確實沒被修改過，那麼伺服器端就應該返回 304 Not Modified，同時 body 不包含任何內容。
所謂的「條件 GET」，是指 GET 的 header 帶上了 If-Modified-Since 或 If-None-Match 欄位。這兩個 header 就是「條件」，如果條件符合了 GET 就應該正常執行，否則就應該返回 304 Not Modified，以便告訴客戶端它想要請求的資源在上一次請求之後沒有被更新過，客戶端可以繼續使用之前的版本。
307 Temporary Redirect
臨時性重定向，且總是使用原請求的方法來進行新請求。
4xx
400 Bad Request
伺服器無法理解請求的格式，客戶端不應當嘗試再次使用相同的內容發起請求。
401 Unauthorized
請求未授權。如果請求 header 沒有 Authorization 欄位，伺服器端應該在返回 401 Unauthorized 的同時在 header 中用 WWW-Authorization 欄位指出授權方式，以便客戶端帶上登錄信息重新發起請求。如果 Authorization 欄位已經存在，則表明登錄信息不正確。
402 Payment Required
需要支付。這是一個在任何瀏覽器中都沒有被實現的狀態碼，僅預留將來使用。
網路曾經有一個部門印過一批背上寫著 402 Payment Require 的衣服，並且開玩笑說這批衣服最適合在互聯網企業員工討薪時穿。
403 Forbidden
禁止訪問。即使使用 Authorization 欄位提供登錄信息也會得到相同的結果。
如果客戶端使用 HEAD 以外的方法請求，403 Forbidden 必須同時在 body 中返回禁止訪問的原因。如果原因不能夠公開，則應該使用404 Not Found。
404 Not Found
找不到如何與 URI 相匹配的資源。伺服器無需指出資源是臨時性不存在還是永久性不存在，但如果伺服器端知道該資源已經被永久性刪除則應該返回 410 Gone。
404 Not Found 是伺服器端在不願意提供理由的情況下拒絕提供資源的最佳借口。
405 Method Not Allowed
請求的方法被拒絕。
如果你有一個 REST API 或 CRUD API 被設計為只讀，那麼在遇到 PUT、POST 或者 DELETE 方法時伺服器端都應該返回 405 Method Not Allowed，同時在 header 的 Allow 欄位說明允許的方法（如 GET 和 HEAD）。
409 Conflict
沖突，且需要用戶手工解決。
如果你使用 git（或者其他源代碼管理軟體），你已經知道「沖突」是什麼了。409 Conflict 通常發生在 PUT 請求時，如果要更新的資源已經被其他人更新過了，你再更新就可能產生沖突。
410 Gone
如果伺服器端將此資源標記為已被永久性刪除，則應該使用 410 Gone 而非 404 Not Found，其用意在於告訴客戶端資源是被有意刪除的，而且刪除是永久性的，客戶端不應該再保留這個 URI 的鏈接。
舉例來說，你有一個 REST API 或 CRUD API 用於向用戶提供優惠信息。有一則優惠的 URI 是 /promotions/1234，但由於優惠活動已經結束了，所以這一則優惠信息不再有效且應當被永久性刪除，那麼這時候伺服器端就應該讓該 URI 永遠返回 410 Gone 了。
412 Precondition Failed
條件判斷失敗，操作不會被執行。
在解釋 304 Not Modified 時提到了「條件 GET」的概念，但「條件」本身也可以應用於非 GET 請求，這時候如果條件判斷失敗伺服器端就應該返回 412 Precondition Failed，同時拒絕執行客戶端請求的方法。
條件請求可以被看作是一種樂觀鎖。它不需要伺服器端有任何邏輯判斷操作是否存在沖突，伺服器端只要記錄資源的時間戳（或其它版本信息）即可。
5xx
500 Internal Server Error
最常見的伺服器端錯誤。
503 Service Unavailable
伺服器端暫時無法處理請求（可能是過載或維護）。
返回 503 Service Unavailable 的意思是當前的狀況是臨時性的，客戶端可以稍後重試。伺服器端可以在返回時通過 header 的Retry-After 欄位告訴客戶端多久後可以重試。如果不提供這個欄位的話，客戶端應當把 503 Service Unavailable 等同於 500 Internal Server Error 處理。
『貳』 ArcGIS Server REST 服務各類API的主要功能
這個問得比較大，REST是一個Web應用程序框架。ArcGIS REST API提供了簡單、開放的介面來訪問和使用ArcGIS Server發布的服務。使用ArcGIS REST API通過URL，可以獲取和操作每一個服務中的所有資源和操作。使用REST API就是通過URL來向GIS伺服器獲取資源的操作。
一般客戶端從伺服器端總是能得到一個資源的表現，在此一般分為兩種類型的資源：
Resources（資源，直接反應了服務本身的信息）
Operations（操作，根據服務本身的資源進行某些處理後得到的結果）
Catalog是整個REST APIURL分層等級的根。根下面是這個Server所發布的服務，一共有8種類型的服務：Map Service、Geocode Service、GP Service、Geometry Service、Image Service、Network Service、GeoData Service和Globe Service。每一種Service下面都有不同的操作和資源，而執行這些操作和獲取這些資源都是通過URL。
再具體的建議參考《ArcGIS Server REST API Help》。
『叄』 REST API 和WebService有哪些不同
從基本原理層次上說，REST 樣式和 SOAP 樣式 Web Service的區別取決於應用程序是面向資源的還是面向活動的。例如，在傳統的WebService中，一個獲得天氣預報的webservice會暴露一個WebMethod。而RESTful WebService暴露的不是方法，而是對象（資源）。
在 REST 的定義中，一個 Web Service總是使用固定的 URI 向外部世界呈現（或者說暴露）一個資源。可以說這是一種全新的思維模式：使用唯一資源定位地址 URI，加上 HTTP 請求方法從而達到對一個發布於互聯網資源的唯一描述和操作。
『肆』 java 要調用別人提供的rest api介面介面是url 比如實現簡單的增加操作 具體實現哪些步驟
第一：先把url存儲下來，配置文件，資料庫等
第二：在相應的action層調用項目裡面的httpClientUtil或者採用apache的httpClient 去請求url,
接下來的操作跟一般的web沒區別了
『伍』 如何使用 Oauth 實現一個安全的 REST API 服務
連續2天的Peyote實驗後（你可能會找到更好的放鬆辦法），結論終於呈現在你眼前：Amazon是擁有最大的、使用最多的在線網路API的網路服務之一，並且根本不支持OAuth！
經過一個下午長時間的狂想之後，你最終敗下陣來，並看到Amazon是如何保持API請求安全的。你不清楚為什麼，但讀完整頁關於如何為Amazon網路服務裝配一個請求後，你依然覺得不完全合理。這個「簽名」和什麼連在一起？代碼示例中的「data」參數是什麼？這樣，你會繼續查找關於「安全API設計」的文章。。。
當遇到其他人問同樣的問題時，你看到一些指出"HMAC"或其他事物的優秀回復，但還是不太確定。
你找到其他鼓勵你使用「HMAC」的文章並且你正H-FINE地使用它，如果有人將「HMAC」解釋成簡明的H_ENGLISH的話。
你的確偶遇了一個有道理的蒸餾的基本概念，它是這樣一簡明的英語描述的：
一個伺服器和客戶端知道一個公鑰和一個私鑰；只有伺服器和客戶端知道私鑰，但每個人都知道公鑰。。。但不關心別人所知道的。
一個客戶端生成一個唯一的HMAC（哈希）表示它到伺服器的請求。通過把請求數據（參數和值或XML/JSON或任何它計劃發送的數據）以及請求數據的散列blob和私鑰結合來實現。
客戶端隨後將這個HASH以及所有它將要發送的參數和值一並發給伺服器。
伺服器接到請求，並使用與客戶端相同的方式重新生成自己獨有的基於提交值的HMAC（哈希）。
然後，伺服器比較這兩個HMAC，如果相同，伺服器就信任這個客戶端並執行請求。
這似乎很直截了當。最初讓你困惑的是，你以為原始請求是經過加密傳送的，但實際上，HMAC方法所做的一切只是使用只有客戶端和伺服器才知道的私鑰將參數生成為一些獨特的校驗和（哈希）。
隨後，客戶端將這個校驗和及原始參數和值發給伺服器，然後伺服器復核校驗和（哈希）以確定它接受客戶端所發的請求。
因為根據假設，只有在客戶端和伺服器知道私鑰，我們假設如果他們的哈希匹配，那麼它們會互相信任，以至伺服器隨即正常處理這個請求。
你知道在現實中，這就相當於某人過來對你說：「Jimmy讓我告訴你把錢給Johnny」，但你不知道這個人是誰，所以你要伸出手去試探他，看看他是否知道這個秘密握手。
如果三次握手證明無誤，則通訊繼續進行，否則中斷通訊。.
你明白了大概是怎麼回事，但還是想會不會還有更好的方法呢？還好，有tarsnap網站 tarsnap幫你答疑解惑。看看亞馬遜是如何解決簽名認證問題的Amazon screwed this up with Signature Version 1.
看完了亞馬遜的web service是如何鑒權的，re-read how Amazon Web Services does authentication 講的確實有道理，整個流程如下:
[客戶端]在調用REST API之前，首先將待發送消息體打包, combine a bunch of unique data together(websevice端將要接收的數據)
[客戶端]用系統分派的密鑰使用哈希(最好是HMAC-SHA1 or SHA256 ) 加密(第一步的數據).
[客戶端]向伺服器發送數據:
用戶身份認證信息例如,用戶ID，客戶ID或是其他能別用戶身份的信息。這是公共API，大家都能訪問的到(自然也包括了那些居心叵測的訪問者)系統僅僅需要這部分信息來區分發信人而不考慮可靠與否(當然可以通過HMAC來判斷可靠性).
發送生成的HMAC碼.
發送消息體（屬性名和屬性值），如果是私有信息需要加密，像是（「mode=start&number=4&order=desc」或其他不重要的信息）直接發送即可.
(可選項)避免重放攻擊 「replay attacks」 o的唯一辦法就是加上時間戳。在使用HMAC演算法時加入時間戳，這樣系統就能依據一定的條件去驗證是否有重放的請求並拒絕.
[伺服器端]接收客戶端發來的消息.
[伺服器端] (參看可選項)檢查接收時間和發送時間的間隔是否在允許范圍內（5-15分）以避免重放攻擊replay attacks.
提示: 確保待檢對象的時區無誤daylight savings time
更新: 最近得到的結論就是直接使用UTC時區而無需考慮DST的問題 use UTC time .
[伺服器端]使用發送請求中用戶信息（比如.API值）從資料庫檢索出對應的私匙.
[伺服器端]
跟客戶端相同，先將消息體打包然後用剛得到的私匙加密（生成HMAC）消息體.
(參看可選項) 如果你使用了加入時間戳的方式避免重放攻擊，請確保服務端生成的加密信息中擁有和客戶端相同的時間戳信息以避免中間人攻擊man-in-the-middle attack.
[伺服器端] 就像在客戶端一樣，使用HMAC哈希加密剛才的信息體.
[伺服器端]
將伺服器端剛生成的哈希與客戶端的對比。如果一致，則通訊繼續；否則，拒絕請求!
提示: 在打包消息體的時候一定要考慮清楚，如果像亞馬遜進行簽名版本1中信息識別那樣會面臨哈希沖突的問題 open yourself up to hash-collisions! (建議：將整個包含URL的請求加密即可!)
特別提示:私匙絕對不能在通訊過程中傳遞，它僅僅用來生成HMAC,伺服器端會自動查詢出它的私匙並重新生成自己的HMAC.我來翻譯公匙僅僅用來區分不同的用戶，即使被破解也無所謂。因為此時的消息無需判斷其可靠性，服務端和客戶端還是要通過私匙來加密（比如，前綴、後綴，倍數等等）
10/13/11更新：Chris最近發現 pointed out 如果在HMAC計算中加入了URI或是HTTP請求/回復，攻擊者更易通過更改末端或是HTTP方法來搞破壞。比如，在HTTP POST方法中將/issue/create改成/user/delete。多謝Chris的提醒!
總結
經過幾天的煎熬，你終於設計出了一個安全的API訪問機制，感到很驕傲吧。更值得驕傲的是，通過這種設計方式很好的避開了另一種常見的API訪問危機：劫持 side-jacking.
會話劫持是通過嗅探出的會話ID來破解短時效的操作數（比如，1小時內）.但採用上面的設計就很好的避免了這一點，因為通訊過程中往來操作均被校驗過，根本無需生成會話ID.
興奮啊.
但是你慢慢的意識到在某些時候確實還是得使用OAuth，have to implement OAuth, 也許就是還未成熟的 isn』t quite ready yet OAuth2.0吧 OAuth 2.0 support
我也剛接觸RESTful架構沒多長時間，只是關注了一下客戶端的包文件部分 client-side libraries.
如果上文中遺漏了什麼，請幫忙之處，我會盡快修訂。如果您對上文中有任何的意見和建議，請留下您的寶貴意見。
或者，也可以給我發郵件，一起討論一下！
留觀室（待解決問題）
<此處已刪除，只要你使用UTC時區 using UTC time 就不會有時差問題了，所以我的提議也沒什麼意義了.>
題外話
如果是為Twitter這種模式開發API呢，那會有成千上萬台手機上安裝被植入公匙私匙的應用private keys embedded in the app。
在設備上，用戶很可能破解出應用中的私匙，這不是很危險么？
是的，是很危險。
那該怎麼辦呢？
按照Twitter的說法，這種情況無法避免。應用需要它的私匙（它們稱之為密匙），那也意味著在安全方面要做出妥協。
目前能做的就是生成應用級別的私匙而非用戶級別的。那樣的話，如果應用被黑了可以禁用直到發布包含新生成私匙的新版本應用。
如果剛更新的私匙又被黑了怎麼辦？
對，這很有可能。你可以自己再加密原有的私匙，或是祈求自己的應用不會再被黑掉.
無所謂，你甚至可以再加密一次私匙但至少這樣你就能在凶險的網路環境中使用自己的新應用了。這總比賬戶被鎖，應用無法使用要好得多.
更新#1:在評論中有很多很好的建議和觀點，我在這引述幾條:
使用nonce 「nonce」來避開重放攻擊 (每次都採用不同的token)並實現idempotentcy implement idempotentcy in your API.
上面的演算法跟雙數據模式的OAutho1.0有95%的相似「95% similar to 『two-legged』 OAuth 1.0「，所以還是看一下OAuth的說明為妙.
通過SSL發送消息可以減少復雜的安全性訪問設計sending all traffic to go over SSL (HTTPS)!
更新 #2: 我又看了一下雙數據模式的OAuth,正如大家指出的，確實跟上面的過程很像。使用OAuth的唯一好處就是有很多現成的客戶端庫文件 OAuth client libraries
關於OAuth需要注意的地方:
OAuth的說明文檔super-specific 指出了如何在HMAC計算中完成轉碼，排序並打包（在OAuth叫「方法標識「）
在OAuth使用HMAC-SHA1加密時，會要求發送端提供一個簡述隨機數。並以此簡述隨機數和時間戳來確保請求的唯一性（潛在的「重放攻擊」 ）原理上，你可以在數據存儲後失效這些數據，但最好還是把它們保存在文件中以便後用.
簡述隨機數可以公開。它就是在關聯某個時間戳時附加的一些欄位。它們的關系就好像一個指紋來確保「12:22pm 收到一條包含HdjS872djas83的消息請求 「這就杜絕了使用中間人重放攻擊的可能，因為所有HMAC加密演算法中都同時含有簡述隨機數和時間戳。如果受到攻擊，它會告訴你」這條消息兩小時前處理過了，你想干什麼呢?!」
這些所有的數據都以逗號分隔並塞入很大的鑒權HTTP包頭中，而並非通過GET方法傳值.
這確實是雙數據模式的OAuth的過人之處。HMAC計算時需要的請求數據無需改變就原封不動的放在那裡，發送過程中的簡述隨機數和時間戳也一樣就連發送請求中的參數也一樣.
『陸』 如何通過Java客戶端程序通過rest介面訪問並上傳文件(文檔)到web伺服器
圖片目錄不在項目路徑下，直接通過HTTP訪問不到，如果你硬是要這么訪問，你可以自己寫一個Servlet，通過流的方式輸出，注意要吧Content-Type設置正確
『柒』 內部系統可以做成通過REST API的方式調用嗎
想要為開發工程師們開發一個既能滿足REST約束條件和原則又不像OAuth OAuth 那樣復雜 the complexity ，僅僅使用簡單的傳值語句或者其它簡單但同樣安全的方法就能實現的web API?
聰明人會有聰明的想法…
問題
直接通過HTTP literally passing the credentials over HTTP以文本方式傳輸鑒權信息可能會被破譯; 尤其在 Gawker incident, 再以文本或是弱加密的方式傳輸鑒權信息是非常不安全的做法 weakly-hashed anything is usually a bad idea.
即便是使用哈希加密後還是很有可能被人根據彩虹表 Rainbow Table破譯出與用戶名匹配的密碼（個別案例）
這可該怎麼辦，真是郁悶…
也許你又會想到很多公共的API popular public APIs在請求中採用雙數據的模式：一個公有值一個（最好是有）只有屬主能訪問的私有值。
」還是有點不對!」這不跟原來（用戶名密碼模式）文本模式差不多麼，還是可能會被（嗅探器）破譯。
這時候你可能准備放棄並採用OAuth模式了，但仍堅信必有某種簡單方法能實現公用webAPI安全訪問私有鑒權信息。
解決方案
連續2天的Peyote實驗後（你可能會找到更好的放鬆辦法），結論終於呈現在你眼前：Amazon是擁有最大的、使用最多的在線網路API的網路服務之一，並且根本不支持OAuth！
經過一個下午長時間的狂想之後，你最終敗下陣來，並看到Amazon是如何保持API請求安全的。你不清楚為什麼，但讀完整頁關於如何為Amazon網路服務裝配一個請求後，你依然覺得不完全合理。這個「簽名」和什麼連在一起？代碼示例中的「data」參數是什麼？這樣，你會繼續查找關於「安全API設計」的文章。。。
當遇到其他人問同樣的問題時，你看到一些指出"HMAC"或其他事物的優秀回復，但還是不太確定。
你找到其他鼓勵你使用「HMAC」的文章並且你正H-FINE地使用它，如果有人將「HMAC」解釋成簡明的H_ENGLISH的話。
你的確偶遇了一個有道理的蒸餾的基本概念，它是這樣一簡明的英語描述的：
一個伺服器和客戶端知道一個公鑰和一個私鑰；只有伺服器和客戶端知道私鑰，但每個人都知道公鑰。。。但不關心別人所知道的。
一個客戶端生成一個唯一的HMAC（哈希）表示它到伺服器的請求。通過把請求數據（參數和值或XML/JSON或任何它計劃發送的數據）以及請求數據的散列blob和私鑰結合來實現。
客戶端隨後將這個HASH以及所有它將要發送的參數和值一並發給伺服器。
伺服器接到請求，並使用與客戶端相同的方式重新生成自己獨有的基於提交值的HMAC（哈希）。
然後，伺服器比較這兩個HMAC，如果相同，伺服器就信任這個客戶端並執行請求。
這似乎很直截了當。最初讓你困惑的是，你以為原始請求是經過加密傳送的，但實際上，HMAC方法所做的一切只是使用只有客戶端和伺服器才知道的私鑰將參數生成為一些獨特的校驗和（哈希）。
隨後，客戶端將這個校驗和及原始參數和值發給伺服器，然後伺服器復核校驗和（哈希）以確定它接受客戶端所發的請求。
因為根據假設，只有在客戶端和伺服器知道私鑰，我們假設如果他們的哈希匹配，那麼它們會互相信任，以至伺服器隨即正常處理這個請求。
你知道在現實中，這就相當於某人過來對你說：「Jimmy讓我告訴你把錢給Johnny」，但你不知道這個人是誰，所以你要伸出手去試探他，看看他是否知道這個秘密握手。
如果三次握手證明無誤，則通訊繼續進行，否則中斷通訊。.
你明白了大概是怎麼回事，但還是想會不會還有更好的方法呢？還好，有tarsnap網站 tarsnap幫你答疑解惑。看看亞馬遜是如何解決簽名認證問題的Amazon screwed this up with Signature Version 1.
看完了亞馬遜的web service是如何鑒權的，re-read how Amazon Web Services does authentication 講的確實有道理，整個流程如下:
[客戶端]在調用REST API之前，首先將待發送消息體打包, combine a bunch of unique data together(websevice端將要接收的數據)
[客戶端]用系統分派的密鑰使用哈希(最好是HMAC-SHA1 or SHA256 ) 加密(第一步的數據).
[客戶端]向伺服器發送數據:
用戶身份認證信息例如,用戶ID，客戶ID或是其他能別用戶身份的信息。這是公共API，大家都能訪問的到(自然也包括了那些居心叵測的訪問者)系統僅僅需要這部分信息來區分發信人而不考慮可靠與否(當然可以通過HMAC來判斷可靠性).
發送生成的HMAC碼.
發送消息體（屬性名和屬性值），如果是私有信息需要加密，像是（「mode=start&number=4&order=desc」或其他不重要的信息）直接發送即可.
(可選項)避免重放攻擊 「replay attacks」 o的唯一辦法就是加上時間戳。在使用HMAC演算法時加入時間戳，這樣系統就能依據一定的條件去驗證是否有重放的請求並拒絕.
[伺服器端]接收客戶端發來的消息.
[伺服器端] (參看可選項)檢查接收時間和發送時間的間隔是否在允許范圍內（5-15分）以避免重放攻擊replay attacks.
提示: 確保待檢對象的時區無誤daylight savings time
更新: 最近得到的結論就是直接使用UTC時區而無需考慮DST的問題 use UTC time .
[伺服器端]使用發送請求中用戶信息（比如.API值）從資料庫檢索出對應的私匙.
[伺服器端] 跟客戶端相同，先將消息體打包然後用剛得到的私匙加密（生成HMAC）消息體.
(參看可選項) 如果你使用了加入時間戳的方式避免重放攻擊，請確保服務端生成的加密信息中擁有和客戶端相同的時間戳信息以避免中間人攻擊man-in-the-middle attack.
[伺服器端] 就像在客戶端一樣，使用HMAC哈希加密剛才的信息體.
[伺服器端] 將伺服器端剛生成的哈希與客戶端的對比。如果一致，則通訊繼續；否則，拒絕請求!
提示: 在打包消息體的時候一定要考慮清楚，如果像亞馬遜進行簽名版本1中信息識別那樣會面臨哈希沖突的問題 open yourself up to hash-collisions! (建議：將整個包含URL的請求加密即可!)
特別提示:私匙絕對不能在通訊過程中傳遞，它僅僅用來生成HMAC,伺服器端會自動查詢出它的私匙並重新生成自己的HMAC.我來翻譯公匙僅僅用來區分不同的用戶，即使被破解也無所謂。因為此時的消息無需判斷其可靠性，服務端和客戶端還是要通過私匙來加密（比如，前綴、後綴，倍數等等）
10/13/11更新：Chris最近發現 pointed out 如果在HMAC計算中加入了URI或是HTTP請求/回復，攻擊者更易通過更改末端或是HTTP方法來搞破壞。比如，在HTTP POST方法中將/issue/create改成/user/delete。
『捌』 怎樣保證到伺服器的 REST 請求是由自己的 APP 發起的
accesstoken是一種方式，早期簡單點的有appid，appkey方式，復雜一點的可以使用RSA加密。伺服器和APP直接大部分通過介面調用，比如用戶列表。/user/list/post到/user/list/裡面有加密的一個token這個是驗證是不是一個合法的訪問者。而且現在很多開發平台比如 。
『玖』 如何使用JFINAL搭建REST介面伺服器
2.7 configHandler(..)
此方法用來配置JFinal的Handler，如下代碼配置了名為ResourceHandler的處理器，Handler可以接管所有web請求，並對應用擁有完全的控制權，可以很方便地實現更高層的功能性擴展。
public void configHandler(Handlers me) { me.add(new ResourceHandler());}