編輯推薦
1.Web API設計、開發與運維zui佳實踐!
2.實例豐富,分析瞭美國各大知名網站的API設計細節。
3.內容詳實,易於理解,Web API新手bi備!
API如果設計得不好,不僅會很難用,而且公開之後的運維也很睏難,因此設計優美的API非常重要。本書認為“設計優美的API易於使用、便於更改、健壯性好、不怕公之於眾”,並基於這一觀點詳細闡述瞭如何有效地設計、開發和運維API、如何避免容易掉入的陷阱等。目標是設計齣訪問URI後返迴XML或JSON等數據的簡潔的API,即XML over HTTP方式或JSON over HTTP方式的API。
內容簡介
本書結閤豐富的實例,詳細講解瞭Web API的設計、開發與運維相關的知識。第1章介紹Web API的概要;第2章詳述端點的設計與請求的形式;第3章介紹響應數據的設計;第4章介紹如何充分利用HTTP協議規範;第5章介紹如何開發方便更改設計的Web API;第6章介紹如何開發牢固的Web API。
作者簡介
水野貴明(作者)
1973年齣生於東京。自由軟件開發者兼技術書作譯者。是JavaScript:The Good Parts、Third-Party JavaScript、 High Performance JavaScript、The Principles of Object-Oriented JavaScript等圖書的日文版譯者,著有《Web應用程序測試方法》(閤著)。
盛榮(譯者)
曾就職於愛立信、Autodesk等公司,長期從事軟件、互聯網技術相關領域的研發、測試等工作。熱愛技術,對IT相關的新聞、曆史等有濃厚興趣。
目錄
目 錄
譯者序 xi
前言 xv
第1章 什麼是Web API 1
1.1 Web API的重要性 3
1.1.1 通過API纔能使用的在綫服務齣現 5
1.1.2 移動應用與API 7
1.1.3 API的經濟學 7
1.2 各種各樣的API模式 8
1.2.1 將已發布的Web在綫服務的數據或功能通過API公開 8
1.2.2 將附加在其他網頁上的微件公開 9
1.2.3 構建現代Web應用 10
1.2.4 開發智能手機應用 11
1.2.5 開發社交遊戲 11
1.2.6 公司內部多個係統的集成 12
1.3 應該通過API公開什麼 12
1.3.1 公開API是否會帶來風險 13
1.3.2 公開API能得到什麼 14
1.4 設計優美的Web API的重要性 15
1.4.1 設計優美的Web API易於使用 15
1.4.2 設計優美的Web API便於更改 16
1.4.3 設計優美的Web API健壯性好 16
1.4.4 設計優美的Web API不怕公之於眾 16
1.5 如何美化Web API 17
1.6 REST與Web API 18
1.7 作為目標對象的開發人員數量與API的設計思想 19
1.8 小結 20
第2章 端點的設計與請求的形式 21
2.1 設計通過API公開的功能 21
2.2 API端點的設計思想 24
2.3 HTTP方法和端點 31
2.3.1 GET方法 32
2.3.2 POST方法 33
2.3.3 PUT方法 33
2.3.4 DELETE方法 34
2.3.5 PATCH方法 35
2.4 API端點的設計 37
2.4.1 訪問資源的端點設計的注意事項 41
2.4.2 注意所用的單詞 43
2.4.3 不使用空格及需要編碼的字符 43
2.4.4 使用連接符來連接多個單詞 44
2.5 搜索與查詢參數的設計 45
2.5.1 獲取數據量和獲取位置的查詢參數 46
2.5.2 使用相對位置存在的問題 47
2.5.3 使用絕對位置來獲取數據 48
2.5.4 用於過濾的參數 49
2.5.5 查詢參數和路徑的使用區彆 52
2.6 登錄與OAuth 2.0 53
2.6.1 access token的有效期和更新 58
2.6.2 其他Grant Type 59
2.7 主機名和端點的共有部分 61
2.8 SSKDs與API的設計 63
2.9 HATEOAS和REST LEVEL3 API 64
2.9.1 REST LEVEL3 API的優點 67
2.9.2 REST LEVEL3 API 67
2.10 小結 68
第3章 響應數據的設計 69
3.1 數據格式 69
3.2 使用JSONP 74
3.2.1 支持JSONP的操作方法 75
3.2.2 JSONP與錯誤處理 77
3.3 數據內部結構的思考方法 79
3.3.1 讓用戶來選擇響應的內容 81
3.3.2 封裝是否必要 82
3.3.3 數據是否應該扁平化 83
3.3.4 序列與格式 85
3.3.5 該如何返迴序列的個數以及是否還有後續數據 88
3.4 各個數據的格式 90
3.4.1 各個數據的名稱 90
3.4.2 如何描述性彆數據 92
3.4.3 日期的格式 95
3.4.4 大整數與JSON 96
3.5 響應數據的設計 97
3.6 齣錯信息的錶示 98
3.6.1 通過狀態碼來錶示齣錯信息 98
3.6.2 嚮客戶端返迴詳細的齣錯信息 99
3.6.3 如何填寫詳細的齣錯信息 101
3.6.4 發生錯誤時防止返迴HTML 102
3.6.5 維護與狀態碼 102
3.6.6 需要返迴意義不明確的信息時 103
3.7 小結 104
第4章 最大程度地利用HTTP協議規範 105
4.1 使用HTTP協議規範的意義 105
4.2 正確使用狀態碼 107
4.2.1 2字頭狀態碼:成功 109
4.2.2 3字頭狀態碼:添加必要的處理 111
4.2.3 當客戶端請求發生問題時 113
4.2.4 5字頭狀態碼:當服務器端發生問題時 115
4.3 緩存與HTTP協議規範 116
4.3.1 過期模型 117
4.3.2 驗證模型 120
4.3.3 啓發式過期 122
4.3.4 不希望實施緩存的情況 123
4.3.5 使用Vary來指定緩存單位 123
4.3.6 Cache-Control首部 125
4.4 媒體類型的指定 127
4.4.1 使用Content-Type指定媒體類型的必要性 129
4.4.2 以x-開頭的媒體類型 130
4.4.3 自己定義媒體類型的情況 131
4.4.4 使用JSON或XML來定義新的數據格式的情況 132
4.4.5 媒體類型與安全性 133
4.4.6 請求數據與媒體類型 134
4.5 同源策略和跨域資源共享 136
4.5.1 CORS基本的交互 137
4.5.2 事先請求 138
4.5.3 CORS與用戶認證信息 139
4.6 定義私有的HTTP首部 139
4.7 小結 141
第5章 開發方便更改設計的Web API 143
5.1 方便更改設計的重要性 143
5.1.1 公開發布的API 144
5.1.2 麵嚮移動應用的API 145
5.1.3 Web服務中使用的API 145
5.2 通過版本信息來管理API 146
5.2.1 在URI中嵌入版本編號 147
5.2.2 如何添加版本編號 149
5.2.3 在查詢字符串裏加入版本信息 151
5.2.4 通過媒體類型來指定版本信息 152
5.2.5 應該采用什麼方法 153
5.3 版本變更的方針 153
5.4 終止提供API 155
5.4.1 案例學習:Twitter廢除舊版本的API 156
5.4.2 預先準備好停止服務時的規範 156
5.4.3 在使用條款中寫明支持期限 159
5.5 編排層 160
5.6 小結 162
第6章 開發牢固的Web API 163
6.1 讓Web API變得安全 163
6.2 非法獲取服務器端和客戶端之間的信息 165
6.2.1 用HTTPS對HTTP通信實施加密 165
6.2.2 使用HTTPS是否意味著100%安全 167
6.3 使用瀏覽器訪問API時的問題 169
6.3.1 XSS 169
6.3.2 XSRF 174
6.3.3 JSON劫持 176
6.4 思考防範惡意訪問的對策 180
6.4.1 篡改參數 181
6.4.2 請求再次發送 183
6.5 同安全相關的HTTP首部 185
6.5.1 X-Content-Type-Options 185
6.5.2 X-XSS-Protection 186
6.5.3 X-Frame-Options 186
6.5.4 Content-Security-Policy 187
6.5.5 Strict-Transport-Security 187
6.5.6 Public-Key-Pins 188
6.5.7 Set-Cookie首部和安全性 189
6.6 應對大規模訪問的對策 191
6.6.1 限製每個用戶的訪問 192
6.6.2 限速的單位 194
6.6.3 應對超齣上限值的情況 195
6.6.4 嚮用戶告知訪問限速的信息 198
6.7 小結 204
附錄A 公開Web API的準備工作 205
A.1 提供API文檔 205
A.2 提供沙盒API 206
A.3 API Console 207
A.4 提供SDK 209
附錄B Web API確認清單 211
精彩書摘
《Web API的設計與開發》:
例如,假設有一個在綫服務同時提供瞭麵嚮智能手機客戶端的API和麵嚮PC的Web站點。用戶通過注冊、登錄來使用該服務。該服務使用cookie來管理Web站點的會話信息。如果該服務在麵嚮智能手機客戶端的API裏也同樣使用cookie來進行會話信息的交互(在智能手機客戶端程序裏生成Cookie首部並發送),導緻會話信息被瀏覽器共享的話,那結果會如何呢?
在這種情況下,即使我們沒有預設會通過瀏覽器來訪問API,實際上僅僅通過瀏覽器發送cookie信息這一操作,也能完成API的認證。當攻擊者在SCRIPT元素裏附加URI時,就有可能通過惡意網站來竊取或篡改機密信息等。
因此,當無需通過瀏覽器來訪問API時,就要使用不同的會話管理方式,或者使用私有HTTP首部來識彆客戶端,或者使用下一節介紹的校驗和的方式等,來防範使用SCRIPT元素從瀏覽器訪問API導緻的安全問題。
……
Web API的設計與開發 下載 mobi epub pdf txt 電子書