基本介紹
內容簡介
《RESTful Web APIs中文版》編輯推薦：近年來，REST的流行導致了各種“RESTful”API的巨大增長，但是這些API卻錯失了很多架構的好處。通過這本實用指南，你將可以學習到如何設計可用的，並能隨著時間不斷進化的REST API。通過專注於跨多種領域的解決方案，《RESTful Web APIs中文版》向你展示了該如何使用那些為世界上最成功的分散式計算系統——全球資訊網而設計的工具，從而來創建強大且安全的套用。你將探索REST背後的概念，學習多種可用於創建基於超媒體API的策略，並在《RESTful Web APIs中文版》一步步的指導下整合你所學到的所有內容，從而去設計RESTful的web API。
審查了包括集合模式和純超媒體在內的API設計策略。
理解如何將超媒體與表述整合進一個一致的API。
探索XMDP和ALPS profile格式是如何幫助你應對web API的“語義挑戰”的。
學習近二十多種標準化的超媒體數據格式。
套用在API實現中使用HTTP的最佳實踐。
使用JSON-LD標準及其他Linked Data方法來創建web API。
理解在嵌入式系統使用REST的CoAP協定。
作者簡介
作者：（美國）Leonard Richardson （美國）Mike Amundsen 譯者：趙震一 李哲
Leonard Richardson， 《Ruby Cookbook》 （O’Reilly）一書的作者，曾創建了包括Beautiful Soup在內的多個開原始碼庫。
Mike Amundsen是包括《Building Hypermedia APIs with HTML5 and Node》（O’Reilly）在內的十幾本為人所稱道的技術圖書的作者。
Sam Ruby是W3C HTML工作組的聯合主席，同時也是IBM新興技術組的一名高級技術人員。
媒體推薦
“這是一本了不起的書！《RESTful Web APIs》覆蓋了當今API領域最重要的趨勢和實踐。”
——John Musser ProgrammableWeb創始人
圖書目錄
序 ⅩⅨ
前言 ⅩⅩⅠ
第1 章 網上衝浪 1
場景1 ：廣告牌 2
資源和表述 2
可定址性 3
場景2 ：主頁 3
短會話（Short Session） 5
自描述訊息（self—descriptive message） 5
場景3 ：連結 6
標準方法 8
場景4 ：表單和重定向 9
套用狀態（Application State） 11
資源狀態（resource state） 12
連通性（connectedness） 13
與眾不同的Web 14
Web API 落後於Web 15
語義挑戰 16
第2 章 一個簡單的API 17
HTTP GET ：安全的投注 18
如何讀取HTTP 回響 19
JSON 20
Collection+JSON 21
向API 寫入數據 23
HTTP POST： 資源是如何生成的 24
由約束帶來解放 26
套用語義所產生的語義鴻溝 27
第3 章 資源和表述 29
萬物皆可為資源 30
表述描述資源狀態 30
往來穿梭的表述 31
資源有多重表述 32
HTTP 協定語義（Protocol Semantics） 33
GET 35
DELETE 36
冪等性（Idempotence） 36
POST—to—Append 37
PUT 38
PATCH 39
LINK 和UNLINK 40
HEAD 40
OPTIONS 41
Overloaded POST 41
應該使用哪些方法？ 42
第4 章 超媒體 45
將HTML 作為超媒體格式46
URI 模板 49
URI vs URL 50
Link 報頭 51
超媒體的作用 52
引導請求 52
對回響做出承諾 54
工作流控制 55
當心冒牌的超媒體！ 56
語義挑戰：我們該怎么做？ 57
第5 章 領域特定設計 59
Maze+XML ：領域特定設計 60
Maze+XML 是如何工作的 61
連結關係 62
訪問連結來改變套用狀態 64
迷宮集合 65
Maze+XML 是API 嗎？ 67
客戶端1 ：遊戲 68
Maze+XML 伺服器 72
客戶端2 ：地圖生成器 74
客戶端3 ：吹牛者 76
客戶端做自己想要做的事 77
對標準進行擴展 77
地圖生成器的缺陷 80
修復（以及修復後的瑕疵） 81
迷宮的暗喻 83
解決語義鴻溝 83
領域特定設計在哪裡？ 83
最終的獎賞 84
報頭中的超媒體 84
抄襲套用語義 84
如果找不到相關的領域特定設計，不要自己製造 86
API 客戶端的種類 86
人類驅動的客戶端 86
自動化客戶端 87
第6 章 集合模式（Collection Pattern） 91
什麼是集合？ 93
鏈向子項的集合 93
Collection+JSON 94
子項的表示 95
寫入模板（Write Template） 98
搜尋模板 99
一個（通用的）集合是如何工作的 100
GET 101
POST—to—Append 101
PUT 和PATCH 101
DELETE 102
分頁 102
搜尋表單 103
Atom 發布協定（AtomPub） 103
AtomPub 外掛程式標準 105
為什麼不是每個人都選擇使用AtomPub ？ 106
語義挑戰：我們應該怎么做？ 107
第7 章 純— 超媒體設計 111
為什麼是HTML？ 111
HTML 的能力 112
超媒體控制項 112
套用語義外掛程式 113
微格式 115
hMaze 微格式 116
微數據 118
改變資源狀態 119
為表單添加套用語義 121
與超媒體相對是普通媒體 125
HTML 的局限性 126
拯救者HTML5？ 127
超文本套用語言 128
Siren 131
語義挑戰：我們現在要怎么做？ 133
第8 章 Profile 135
客戶端如何找尋文檔？ 136
什麼是Profile ？ 137
連結到Profile 137
Profile 連結關係 137
Profile 媒體類型參數 138
特殊用途的超媒體控制項 139
Profile 對協定語義的描述 139
Profile 對套用語義的描述 140
連結關係 141
不安全的連結關係 142
語義描述符 142
XMDP ：首個機器可讀的Profile 格式 143
ALPS 146
ALPS 的優勢 150
ALPS 並不是萬金油 152
JSON—LD 153
內嵌的文檔 156
總結 158
第9 章 API 設計流程 161
兩個步驟的設計流程 161
七步驟設計流程 162
第1 步：羅列語義描述符 163
第2 步：畫狀態圖 164
第3 步：調整命名 168
第4 步：選擇一種媒體類型 172
第5 步：編寫Profile 173
第6 步：實現 174
第7 步：發布 174
實例：You Type It， We Post It 177
羅列語義描述符 177
畫狀態圖 178
調整名稱 179
選擇一種媒體類型 180
編寫Profile 181
設計建議 182
資源是實現的內部細節 182
不要掉入集合陷阱 183
不要從表述格式著手 184
URL 設計並不重要 184
標準名稱優於自定義名稱 186
設計媒體類型 187
當你的API 改變時 189
為現有API 添加超媒體 194
改進基於XML 的API 195
值不值得？ 196
Alice 的第二次探險 196
場景1 ：沒有意義的表述 196
場景2 ：Profile 198
Alice 明白了 200
第10 章 超媒體動物園 203
領域特定格式 204
Maze+XML 204
OpenSearch 205
問題細節文檔 205
SVG 206
VoiceXML 208
集合模式的格式 210
Collection+JSON 211
Atom 發布協定 211
OData 212
純超媒體格式 219
HTML 219
HAL 220
Link 報頭 222
Location 和Content—Location 報頭 222
URL 列表 223
JSON 主文檔（Home Documents） 223
Link—Template 報頭 224
WADL 225
XLink 226
XForms 227
GeoJSON ：一個令人困惑的類型 228
GeoJSON 沒有通用的超媒體控制項 230
GeoJSON 沒有媒體類型 232
從GeoJSON 學習到的經驗 233
語義動物園 234
連結關係的IANA 註冊表 234
微格式WiKi 235
來自微格式Wiki 的連結關係 236
第11 章 API 中的HTTP 241
新HTTP/11 規範 242
回響碼 242
報頭 243
表述選擇 243
內容協商（Content Negotiation） 243
超媒體選單 244
標準URL（Canonical URL） 245
HTTP 性能 246
快取（Caching） 246
條件GET 請求（Conditional GET） 247
Look—Before—You—Leap 請求 249
壓縮 250
部分GET 請求（Partial GET） 250
Pipelining 251
避免更新丟失問題 252
認證 254
WWW—Authenticate 報頭和Authorization 報頭 255
Basic 認證 255
OAuth 10256
OAuth 10 的缺點 259
OAuth 20260
何時不採用OAuth 261
HTTP 擴展 261
PATCH 方法 262
LINK 和UNLINK 方法 262
WebDAV 263
HTTP 20264
第12 章 資源描述和Linked Data 267
RDF 268
RDF 將URL 作為URI 對待 270
什麼時候使用描述策略 271
資源類型 273
RDF Schema 274
Linked Data 運動 277
JSON—LD 278
將JSON—LD 作為一種表述格式 279
Hydra 280
XRD 家族 285
XRD 和JRD 285
Web 主機元數據文檔 286
WebFinger 287
本體動物園（Ontology Zoo） 289
schemaorg RDF 289
FOAF 290
vocaborg 290
總結：描述策略生機盎然！ 290
第13 章 CoAP： 嵌入式系統的REST 293
CoAP 請求 294
CoAP 回響 294
訊息種類 295
延遲回響（Delayed Response） 296
多播訊息（Multicast Message） 296
CoRE Link Format 297
結論：非HTTP 協定的REST 298
附錄A 狀態法典 301
附錄B HTTP 報頭法典 325
附錄C 為API 設計者準備的Fielding 論文導讀 349
辭彙表 365
序言
“大多數軟體系統在創建時都有一個隱含的假設：整個系統處在一個實體的控制之下；或者至少參與到系統中的所有實體都向著一個共同目標行動，而不是有著各自不同的目標。當系統在網際網路上開放地運行時，無法安全地滿足這樣的假設。”
——Roy Fielding
Architectural Styles and the Design of Network-based Software Architectures“ Discordia 信徒應該一直使用官方的Discordian文檔編號系統。”
——Malaclypse the Younger 和 Lord Omar Khayyam Ravenhurst
我要向你展示一種可以更好地進行分散式計算的方式，它使用了有史以來最成功的分散式系統，即全球資訊網的根本思想。如果你已經決定（或者你的經理已經決定）需要為你的公司發布一個web API的話，我希望你能夠讀一下這本書。不管在你計畫中的是一個公共的API，還是一個純粹的內部API，抑或是一個只有受信夥伴可以訪問的API——它們都可以從REST的哲學中受益。
如果你想學習如何編寫API客戶端的話，那么這本書對你來說並不是必要的。這是因為大多數現有的API設計都基於一些有著數年之久的假設，而這些假設正是我想要摧毀的。
大部分今天的API都有著一個很大的問題：一旦部署，它們將無法改變。有一些大名鼎鼎的API會在一次部署後多年保持靜態不變，即使圍繞它們的行業發生著改變，這是因為要改變它們非常困難。
但是RESTful架構是為掌控變化而設計的。全球資訊網由數百萬的網站組成，運行在數千種不同的伺服器實現之上，並且經歷著周期性的重新設計。這些網站被數十億的用戶訪問著，而這些用戶使用著幾十種硬體平台之上的數百種不同的客戶端實現。你的部署在一開始可能看上去不會如此混亂，但是當你的套用越發接近web的規模時，你將會看到越發相似的混亂景象。
要改變一個非常簡單的系統通常都是很容易的。在規模很小時，一個RESTful系統比一個一鍵式的解決方案（push-button solution）需要花費更多預支的設計成本。但是當你的API逐漸成熟並開始發生變化時，你將會真正需要一些像REST這樣的方式來應對變化。
y一個商業上成功的API將保持連續多年的可用。一些API擁有數百甚至是數以千計的用戶。就算問題域只是偶然地發生變化，對客戶端帶來的累積效應將是非常大的。
y有一些API一直都在發生變化，新的數據元素和業務規則不斷地被添加進來。
y在某些API中，每個客戶端都可以通過改變工作流來使其適合自己的需求。即使API自身從不變化，每個客戶端對API的經歷（鑒於經歷不同的工作流）將會不同。
y編寫API客戶端的人通常不會和編寫伺服器的人隸屬於同一個團隊。所有向公共開放的API都屬於這一類。
如果你不知道外部的客戶端是哪種類型的話，你需要在做出變化時格外小心——否則你就需要一個能夠在發生變化時保證不會破壞所有客戶端的設計。如果你為你的API複製了現有的設計，你將很可能只是在重複以往犯過的錯誤。不幸的是，大部分的改進發生在幕後，它們大都還處於實驗階段並需要經過漫長的標準流程。我將會在本書中討論到數十種特定的技術，包括很多還仍然處於開發之中。但是我的主要目標是要教會你REST的基本原則。通過對這些內容的學習，你將可以對任何實驗成果以及那些通過流程審核的標準善加利用。
這裡有兩個我想在本書中嘗試解決的具體問題：重複的工作以及對超媒體的逃避。讓我們來看看它們。
重複的工作
現今已發布的API都是根據託管它們的公司的名字進行命名的。我們談論著“Twitter API”、“Facebook API”和“Google+ API”。這三套API做著相似的事情。它們都擁一些用戶賬戶的概念，（在其他方面）它們都允許用戶向自己的賬戶發布文本信息。但是每個API都具有完全不同的設計，學習一個API並不能幫助你學習下一個。當然，Twitter、Facebook和Google都是互相競爭的大型公司，它們並不想讓你很容易地就學會它們競爭對手的API。但是小公司和非營利性組織也在做著相同的事。它們重新設計著自己的API，就好比從來沒有人在這方面有過相似的想法一樣，但是這干擾了它們想讓人們實際使用它們的API的目標。
讓我來向你展示一個例子吧。網站Programmable Web擁有著一個超過8000個API的目錄。當我正在編寫此書之時，它已經收錄了57種微博API——這些API的主要用途是向用戶的賬戶發布文本信息注2。很不錯，有57家公司在這個領域發布了API，但是我們真的需要57種不同的設計嗎？我們在這裡討論並不是那些複雜難懂的業務，例如保險政策或法規守則，我們討論的只是向用戶賬號發布少量的文本信息。你想成為那個設計第58種微博API的人嗎？
最顯而易見的解決方案便是創建一個微博API的標準。但是我們已經有了一個可以很好工作的標準：Atom發布協定（Atom Publishing Protocol）。它發布於2005年，然而幾乎沒有人使用它。有一些關於API的原因，使得每個人都想從頭開始設計他們自己的API，即使從業務的角度來看這並沒有什麼意義。
我不認為憑我一個人的力量就能結束這種無用功，但是我確實認為可以將問題分解成若干有意義的小塊，然後提供一些方式來讓新的API可以復用已經完成的這些工作。
超媒體很難
早在2007年，Leonard Richardson 和Sam Ruby編寫了本書的前身，RESTful Web Services(O'Reilly)。那本書同樣也嘗試於解決兩個大的問題。其中一個問題已經被解決，而另一個卻沒有任何進展。
第一個問題是：在2007年，在API設計的多個陣營中，REST學派正在與使用基於SOAP等重量級技術的對手學派進行對峙，他們忙於應對來自對方的對REST學派合理性的質疑。RESTful Web Services一書的出現打破了這種對峙的僵局，有效地為RESTful設計原則防禦了來自SOAP學派的進攻。
很好，這場對峙已經結束，而REST贏得了勝利。SOAP API仍在被使用著，不過僅限於那些起初支持SOAP學派的大公司。幾乎所有面向公眾的API口頭上都說自己遵守了RESTful原則。
這又將我們帶到了第二個問題：REST並不只是一個技術辭彙——它同樣還是一個行銷術語。在很長一段時間裡，REST成了一個口號，它象徵著任何站在SOAP學派對立面的勢力。任何沒有使用SOAP的API都將自己標榜為REST，即使它的設計與REST毫無關係甚至是違背了REST的基本原則。這樣做是錯誤的，是令人困惑的，它給REST這個技術辭彙帶來了一個壞名聲。
這種情況自2007年便有了較大的改善。每當我審視那些新的API，我看到了開發者們的工作，可以看得出，這些開發人員是理解那些我將在本書前幾章中解釋的概念的。今天大部分舉著REST大旗的開發者都理解資源和表述，理解如何使用URL來為資源命名，以及如何正確地使用HTTP方法。因此本書的前三章將不需要做過多的事情，只需讓新的開發者加速趕上我們即可。
但是在REST中，還有一個方面令大部分的開發人員仍然無法理解，即：超媒體。我們都理解Web環境中的超媒體。它只是作為代表連結的一個華麗的辭彙。網頁經過互相的連結，隨即產生了全球資訊網，全球資訊網便是由超媒體驅動的。但是，貌似只要在web API中涉及到超媒體，我們便有了心理障礙。這是一個大問題，因為超媒體是一項能讓web API優雅處理變化的特性。
從RESTful Web APIs一書的第4章開始，我的首要目標便是教會你超媒體的工作原理。如果你從未聽到過這個詞，我將會結合其他重要的REST概念向你講授該詞。如果你聽到過超媒體，但是這個概念嚇到了你，我將會盡我所能來為你建立勇氣。如果你無法將超媒體裝進你的大腦，我將會以各種我所能想到的方式來向你展示超媒體，直到你記住並理解它。
RESTful Web Services一書也涉及到了超媒體，但是這並不是該書的重心所在。就算跳過該書的超媒體部分也可以照樣設計出一個功能性的API。相比之下，RESTful Web APIs則是一本真正有關超媒體的書。
我之所以這樣做是因為超媒體是REST最重要的一個方面，也是最不被理解的一個方面。在我們完全理解超媒體之前，REST將會被繼續視為一個行銷術語，而不是對處理分散式計算複雜性的一次認真的嘗試。
這本書講了什麼？
前4個章節介紹了REST背後的概念，並將其套用於web API。
第1章，網上衝浪
這一章通過一個你已經熟悉的RESTful系統：網站，來對基本的術語進行了說明。
第2章，一個簡單的API
這一章將我們在Web上的經驗轉換到了一個可程式API中，該API與第1章中所討論的網站具有相同功能。
第3章，資源和表述
資源是HTTP中的基本概念，而表述則是REST中的基本概念。本章對它們之間是如何進行關聯的進行了說明。
第4章，超媒體
超媒體是一種缺失的材料，可以將它和表述一起整合進一個一致的API。本章展示了超媒體可以做些什麼，並大都使用了你已經熟悉的超媒體數據格式：HTML。
接下去的4個章節描述了用於設計超媒體API的不同策略：
第5章，領域特定設計
顯而易見的一個策略是設計一個全新的標準來處理你的具體問題。我使用了Maze+XML標準來舉例說明。
第6章，集合模式（Collection Pattern）
很特別的一個模式：集合模式，在API設計中出現了一次又一次。在這一章中，我展示了兩個不同的標準：Collection+JSON和AtomPub，它們都實現了這種模式。
第7章，純-超媒體設計
當集合模式無法滿足你的需求時，你可以使用一種通用的超媒體格式來傳達任意的表述。這一章使用了3種通用超媒體格式（HTML、HAL和Siren）作為實例來展示上述方式是如何工作的。這一章同樣還介紹了HTML微格式和微數據，並以此引出了下一章的內容。
第8章，Profile
Profile可以用於填平某種數據格式（可以被多種不同的API使用）與某個特定API實現之間的鴻溝。我所推薦的profile格式是ALPS，但是我同樣也提到了XMDP和JSON-LD。
在這一章中，我給出的建議開始超越了編寫本書時的藝術狀態（outstrip the state of the art）。因此我不得不為本書開發了ALPS格式，因為當時還沒有其他可以完成這項工作的選擇。如果你已經對基於超媒體的設計非常熟悉，那么你可以跳過前面的部分直接來到第8章，但是我不認為你應該跳過第8章。
第9章到第13章涉及到了例如選擇正確的超媒體格式以及如何充分利用HTTP協定這些實用主題。
第9章，API設計流程
這一章將本書到目前為止討論過的所有內容整合在了一起，並給出了一個用於設計RESTful API的按部就班的指引。
第10章，超媒體動物園
為了展示超媒體的能力，本章討論了近20種標準化的超媒體數據格式，它們中的大部分並沒有在本書的其他章節中有所涉及。
第11章，API中的HTTP
本章給出了在API實現中使用HTTP的一些最佳實踐。我同樣也討論了一些HTTP的擴展，包括即將到來的HTTP 2.0協定。
第12章，資源描述和Linked Data
Linked Data是語義網社區用以實現REST的方法。JSON-LD毫無疑問是最重要的Linked Data標準。我們曾在第8章談到過它，而我在本章中對它進行了重溫。本章同樣討論了RDF數據模型和一些我在第10章沒能談到的基於RDF的超媒體格式。
第13章，CoAP：嵌入式系統的REST
本章通過對CoAP的討論結束了本書的核心部分，CoAP是一個完全沒有使用HTTP的RESTful協定。
附錄A，狀態法典
作為對第11章的擴展，本附錄對HTTP規範中定義的41個標準狀態碼以及一些作為擴展定義的有用的狀態碼進行了深入的考察。
附錄B，HTTP報頭法典
與附錄A相似，本附錄也是對第11章的擴展。它為HTTP規範中定義的46個請求和回響報頭，以及一些擴展提供了詳細的概述。
附錄C，為API設計者準備的Fielding論文導讀
本附錄包括了一個圍繞REST的基礎文檔（即Fielding論文）展開的深度討論，用以說明該文檔在API設計中的意義。
辭彙表
該辭彙表包含了你在RESTful Web APIs一書中會經常遇到的一些術語的定義。如果你想要熟悉基本概念，或者是需要一個快速的、用於瀏覽特定概念定義的提示工具，那么這將是一個很好的去處。
這本書沒講什麼
RESTful Web Services是最早有關REST的一部書籍，並且涉及了很多的背景知識。幸運的是，現在已經有著超過一打的關於REST的各個方面的書，而這樣便讓RESTful Web APIs可以騰出精力來專注於核心的概念。
為了保持本書的專注度，我去除了部分你可能會希望我覆蓋到的主題。我想要告訴你這本書沒講什麼，這樣你便可以選擇不購買本書，從而不會為此感到失望：
y本書沒有涉及到客戶端編程。編寫客戶端來消費基於超媒體的API是一種新的挑戰。眼下，對一個通用的API客戶端來說，我們可以擁有的就是一個能夠傳送HTTP請求的代碼庫。這在2007年如此，時至今日仍然如此。因為問題存在於伺服器端。當你要為一個現有的API編寫客戶端時，你將只能仰仗API設計者。我無法給你任何通用的建議，因為現在並不存在跨API的一致性。這就是為什麼我在本書中鼓動大家保持對伺服器端一致性的積極性的原因。當API之間變得更加相似，我們也就可以編寫更為精細的客戶端工具。
第5章包含了一些示例的客戶端實現，並嘗試對不同類型的客戶端進行歸類，但是如果你想要一本全部關於API客戶端的書，那么這本書並不適合你。我不認為目前市場上存在著你想要的書。
y世界上部署最廣泛的API客戶端應當屬JavaScript的XMLHttpRequest代碼庫。在每一個瀏覽器中都擁有一份該代碼的副本，而當今大部分的網站也都構建於那些專門設計供XMLHttpRequest消費的API之上。對於本書來講，這個領域過於龐大而無法完全涉及。市場上有著全篇專門講述JavaScript代碼庫的書籍。
y我花費了相當多的時間來討論HTTP的機制（第11章、附錄A和附錄B），但是我沒有覆蓋到任何具有深度的特定HTTP主題，有一些主題，尤其是關於快取和代理這樣的HTTP中間組件的相關主題，我只是簡單地在本書中有所涉及。
yRESTful Web Services重點專注於將你的業務需求拆分成一組互相關聯的資源。根據我2007年以來的經驗，我深信將API設計作為一種資源設計來思考可以有效地避免考慮超媒體。但本書卻採用了一種截然不同的方式，它專注於表述和狀態轉換，而非資源。
也就是說，資源設計的方式無疑也是有效的。如果想聽聽在該方向發展的建議，我推薦由Subbu Allamaraju編著的RESTful Web Services Cookbook(O’Reilly)。
管理備註
本書有兩名作者（Leonard 和Mike），但是在編寫本書的過程中，我們被合併成了一個第一人稱，即“我”。
本書中的內容沒有與任何特定的程式語言綁定。所有的代碼都採用了在網路協定（通常是HTTP）中傳送的訊息格式（通常是JSON或XML文檔）。我將假定你已經熟悉了常規的編程概念，比如反模式和廣度優先搜尋，以及你對全球資訊網是如何工作的有著一個基本的理解。
我將不會呈現真實的代碼，但是我在第1章、第2章以及第5章中所討論的伺服器和客戶端背後的真實代碼是存在的。你可以通過RESTful Web APIs一書的GitHub倉庫，或者是通過官方的網站來獲取這些代碼，從而可以自行將它運行起來。這些客戶端和伺服器是採用JavaScript編寫的，使用的是Node代碼庫。
我之所以選擇Node是因為它讓我可以使用相同的程式語言來編寫客戶端及服務端的代碼。你無須為了理解某個客戶-伺服器事務的兩端而需要費神地在兩種程式語言之間來回切換。Node是開源的，並且可以運行在Windows、Mac和Linux系統上。它很容易在這些作業系統上進行安裝，而你應該無須碰觸太多的麻煩就可以獲取這些例子，並將它們運行起來。
我將這些代碼託管在GitHub上，因為隨著時間的變化，我可以非常容易地更新這些實現。這同樣也使得讀者們可以為這些示例的客戶端和伺服器貢獻其他程式語言的移植版本。
