之前寫了個六步實現Rest風格的API，詳述了怎麼開發Rest風格的服務。Rest是基於HTTP的，有必要知道，HTTP是一個簡單的基於“請求/響應”的協議，它初始時候只是設計用來獲取靜態的或動態生產的內容。HTTP不支援事務，簡單的來說，在接受處理完請求像想客戶端傳送完響應後，HTTP伺服器即認為它的工作已經完成了。這個時候網路或者客戶端發生了錯誤，伺服器端是完全不知道的。如果客戶端決定重試請求，伺服器只會將同樣的事情再做一遍，有的時候這會造成應用資料的不一致。因此，在開發支援內容更改的Rest服務的時候，需要特別小心。

忽略TCP連線建立的過程，一個HTTP請求的全過程包括：

1. 客戶端組裝請求資料，包括HTTP的頭，內容等等
2. 客戶端發出請求，向網路發出資料，伺服器端接受資料
3. 伺服器將請求解析成自己的資料格式
4. 伺服器端按照請求資料處理請求
5. 伺服器端處理完請求後傳送響應回客戶端，客戶端接受到響應
6. 客戶端解析響應
7. 客戶端做後續業務處理

要保證Rest服務的健壯性，就必須考慮HTTP請求的整個過程。在整個過程的任何一個階段出現問題的時候，都必須有一個合理的後續處理。

一，客戶端組裝資料並通過網路發出請求

在這個階段出現問題是很容易處理的，這個時候請求還沒到達伺服器。

伺服器沒有處理請求，也即還沒做任何改變資料的操作。客戶端一段檢測到錯誤，可以根據錯誤的原因做下一步處理。如果是組裝資料的過程中資料有問題，那中止當前處理即可；如果是通過網路傳送資料的時候有問題，比如連線不到主機或者網路連線中斷，那客戶端可以根據系統特點選擇重試幾次請求。

二，伺服器解析請求

這個時候，伺服器也還沒有開始處理資料，所以也還不會對資料產生影響。

這個階段出錯的原因可能多重多樣，比如請求資料格式不對，或者伺服器的某些元件出問題造成無法繼續處理請求，或者伺服器出現了某些沒有預料到的異常。但總的來說，錯誤應該分為兩類：一類是客戶端應該重試的，一類是客戶端不該重試的。假如伺服器突然發生了一個沒預料到的異常，比如到資料庫的連線突然中斷，這個時候客戶端重試請求有很大可能會成功；而如果伺服器發現客戶端傳送過來的資料不符合規範，那可以直接要求客戶端解決問題後在傳送重試。更好的分類方法是按照HTTP協議關於響應碼http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

三，伺服器端處理請求

這一階段其實和"伺服器解析請求，準備處理資料"階段類似。不同點是這一階段可以已經開始處理資料並在處理過程中出現問題。

解決方法就是，伺服器應該保證，一旦開始修改資料，那就必須是完全的修改，或者是完全的不修改。說白了就是，伺服器應該保證請求的處理應該在單一的完整的事務中。所以如果這個階段出現問題，事務回滾後，伺服器的狀態就和"伺服器解析請求，準備處理資料"階段一樣了，皆可按"伺服器解析請求，準備處理資料"階段的處理方式處理。

四，伺服器端傳送響應回客戶端，客戶端接受響應

伺服器如果成功的處理了請求並提交了資料，這個時候伺服器已經完全的接受並處理了請求，差的只是將處理的結果告訴客戶端。

這個階段的問題有兩種：一種是伺服器在組裝返回資料的時候出現了異常；另外一種是伺服器在通過網路向客戶端傳送資料的時候網路出現異常。

如果一個請求處理到了這個階段，不管是那種問題，這個時候出現的任何問題應該都和客戶端無關了。伺服器既然已經接受並處理了請求，那說明客戶端發來的請求是正確的，如果伺服器在準備返回結果的時候出錯，要麼是伺服器的bug，要麼是伺服器出現異常。忽略bug的情況，如果伺服器出現異常，那麼這個時候伺服器應該返回給客戶端一個特殊的標示（比如一個特別的響應嗎），代表已經處理請求。

伺服器在傳送資料給客戶端的時候出問題是整個系統裡最難處理的部分，因為客戶端只知道網路出問題，但是完全不知道伺服器對請求處理結果如何。如果伺服器沒處理這個請求的話，客戶端重試請求，伺服器會再將錯誤傳送給客戶端一次，這通常沒大問題；但是如果伺服器已經處理了第一次的請求，客戶端重試就會造成同樣的請求被處理了兩次。為了確保伺服器即便對同一個請求處理了多次也不影響資料一致，伺服器必須保證HTTP方法的“冪等”，簡單的說就是，任何一個Rest請求都是可以重複請求多次的，如果不出現異常，伺服器處理完一次的結果和處理完多次的結果應該是一樣的。我們可以利用Rest服務資源都有一個ID的原則處理這個問題，在客戶端的任何請求（包括建立）裡都必須附上請求資源的ID，伺服器每次處理的時候都是處理對應ID的那條資料，這樣任何一個資源的最終狀態必定是最後一個請求的結果，如果一個請求被重複多次處理，也不會產生資料的不一致。特別指出，建立一條資源的時候也要附上ID（ID可以客戶端生成或者伺服器提供介面生成），不然的話，伺服器必然會產生兩條一樣的資料。

五，客戶端解析響應並做後續業務處理

這個階段和“客戶端組裝資料並通過網路發出請求”類似，其實它已經和伺服器沒太大關係了。伺服器如果完全傳送了響應，但是客戶端解析不正確，多是伺服器和客戶端不一致造成；如果認為是伺服器響應的問題，有了前一步我們討論的保證，再重試一次也是可以的。

參考資料：http://hc.apache.org/httpclient-3.x/exception-handling.html#Transport%20exceptions

關鍵字： REST，健壯性，robust

 版權所有，轉載請註明來源