Web Api 內部數據思考 和 利用http緩存優化 Api

在上篇《Web Api 端點設計 與 Oauth》後，接着咱們思考Web Api 的內部數據：

其餘文章：《API接口安全增強設計方法》

第一  實際使用應該返回怎樣的數據 ？

　　如何減小api訪問次數很是重要，可是咱們會遇到，當咱們儘量的返回多的信息，多的字段，那麼一次請求，將會帶來大量的毫無心義的信息。當咱們儘量的節約，那麼客戶端須要屢次請求才能拿到想要的數據，因而高不成，低不就。

　    優化方法：讓客戶端來選擇響應的內容，例：

http://api.example.com/v1/users/12345?fields=name,age

經過fields來指定想要返回的字段，那麼還能夠進行怎樣的分類呢？

　　利用響應羣來獲取想要的數據

small ：
字段1，字段2，字段3

medium：
字段1，字段2，字段3，字段4，字段5，字段6

large：
字段1，字段2，字段3，字段4，字段5，字段6，字段7，字段8

　　經過分配group參數，來指定想要的哪些羣組

第二 狀態碼是否必要？

　　咱們來看一下某些數據：

{ 「status」 : { "result" : "success", "errorCode" : 0, } "response" :{ .......實際的數據...... } } 

　　咱們寫接口經常有這個習慣，將狀態碼寫於返回值中，這樣也能夠，但咱們常常忽略了，web api 大部分都是基於http協議，能夠說http已經完成了封裝的工做。http協議首部能夠放置狀態碼，能夠選擇合適的狀態碼來返回。然而不少人都沒有處理這個狀態嗎。我之前在對接的過程當中，便和對接的公司產生了歧義。

　　返回的json數據中的code是0，失敗的錯誤碼，但對方提出了問題，爲何已經返回失敗的錯誤碼，但大家的http狀態碼是爲200.

　　回到問題自己，我我的認爲狀態碼是須要的，但同時也要作好http狀態碼的處理，這樣作出來的api不容易讓人產生誤解。

第三 數據是否應該扁平化 ？

　　咱們來看兩個例子：

具備層級關係的： { "id" : 1111 , "message" : "hello" , "sender" : { "id" : 123, ....... } "receiver" : { "id" : 123, ...... } }

使用扁平化的方式： { "id" : 1111 , "message" : "hello" , "sender_id" : 123, "sender_....." : ...., "receiver_id" : 123
    "receiver_...." : ...., }

這種狀況咱們要具體分析，上述那種狀況，能夠明顯的看出接受方receive，和發送方send，那麼此時用層級關係比較好

而像下述這種狀況：

使用層級形式：

{ "id" : 23245, "name" : 'xxx', "profile" :{ "birthday" : 45, "gender" : "male", } }

使用扁平化方式：

{ "id" : 23245, "name" : 'xxx', "birthday" : 45, "gender" : "male", }

這種狀況下，使用層級跟使用扁平化沒什麼區別，而使用層級還會讓json的尺寸變大，那咱們能夠在此用扁平化

第四 狀態碼太多，大體分類是？

HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，後兩個數字沒有分類的做用。HTTP狀態碼共分爲5種類型：

HTTP狀態碼分類
分類	分類描述
1**	信息，服務器收到請求，須要請求者繼續執行操做
2**	成功，操做被成功接收並處理
3**	重定向，須要進一步的操做以完成請求
4**	客戶端錯誤，請求包含語法錯誤或沒法完成請求
5**	服務器錯誤，服務器在處理請求的過程當中發生了錯誤

 羅列各類狀態碼我就不羅列了。

利用http緩存優化 Api

 一）強制緩存

        強制緩存，在緩存數據未失效的狀況下，能夠直接使用緩存數據，那麼瀏覽器是如何判斷緩存數據是否失效呢？在沒有緩存數據的時候，瀏覽器向服務器請求數據時，服務器會將數據和緩存規則一併返回，緩存規則信息包含在響應header中。
　　對於強制緩存來講，響應header中會有兩個字段來標明失效規則（Expires/Cache-Control）
使用chrome的開發者工具，能夠很明顯的看到對於強制緩存生效時，網絡請求的狀況

　   Expires
　　Expires的值爲服務端返回的到期時間，即下一次請求時，請求時間小於服務端返回的到期時間，直接使用緩存數據。
不過Expires 是HTTP 1.0的東西，如今默認瀏覽器均默認使用HTTP 1.1，因此它的做用基本忽略。
另外一個問題是，到期時間是由服務端生成的，可是客戶端時間可能跟服務端時間有偏差，這就會致使緩存命中的偏差。
因此HTTP 1.1 的版本，使用Cache-Control替代。

　　Cache-Control
　　 Cache-Control 是最重要的規則。常見的取值有private、public、no-cache、max-age，no-store，默認爲private。
　　private:             客戶端能夠緩存
　　public:              客戶端和代理服務器均可緩存（前端的同窗，能夠認爲public和private是同樣的）
　　max-age=xxx:   緩存的內容將在 xxx 秒後失效
　　no-cache:          須要使用對比緩存來驗證緩存數據（後面介紹）
　　no-store:           全部內容都不會緩存，強制緩存，對比緩存都不會觸發（對於前端開發來講，緩存越多越好，so...基本上和它說886）

 例如：

圖中Cache-Control僅指定了max-age，因此默認爲private，緩存時間爲31536000秒（365天）
也就是說，在365天內再次請求這條數據，都會直接獲取緩存數據庫中的數據，直接使用。

 

 二）對比緩存
　　對比緩存，顧名思義，須要進行比較判斷是否可使用緩存。
　　瀏覽器第一次請求數據時，服務器會將緩存標識與數據一塊兒返回給客戶端，客戶端將兩者備份至緩存數據庫中。
　　再次請求數據時，客戶端將備份的緩存標識發送給服務器，服務器根據緩存標識進行判斷，判斷成功後，返回304狀態碼，通知客戶端比較成功，可使　　用緩存數據。
第一次訪問：

再次訪問：
：

經過兩圖的對比，咱們能夠很清楚的發現，在對比緩存生效時，狀態碼爲304，而且報文大小和請求時間大大減小。
緣由是，服務端在進行標識比較後，只返回header部分，經過狀態碼通知客戶端使用緩存，再也不須要將報文主體部分返回給客戶端。

對於對比緩存來講，緩存標識的傳遞是咱們着重須要理解的，它在請求header和響應header間進行傳遞，
一共分爲兩種標識傳遞：

Last-Modified  /  If-Modified-Since
Last-Modified：
服務器在響應請求時，告訴瀏覽器資源的最後修改時間。

If-Modified-Since：
再次請求服務器時，經過此字段通知服務器上次請求時，服務器返回的資源最後修改時間。
服務器收到請求後發現有頭If-Modified-Since 則與被請求資源的最後修改時間進行比對。
若資源的最後修改時間大於If-Modified-Since，說明資源又被改動過，則響應整片資源內容，返回狀態碼200；
若資源的最後修改時間小於或等於If-Modified-Since，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續使用所保存的cache。



Etag  /  If-None-Match（優先級高於Last-Modified  /  If-Modified-Since）
服務器響應請求時，告訴瀏覽器當前資源在服務器的惟一標識（生成規則由服務器決定）。


If-None-Match：
再次請求服務器時，經過此字段通知服務器客戶段緩存數據的惟一標識。
服務器收到請求後發現有頭If-None-Match 則與被請求資源的惟一標識進行比對，
不一樣，說明資源又被改動過，則響應整片資源內容，返回狀態碼200；
相同，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續使用所保存的cache。