在上篇《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。
