摘要：狀態(tài)碼的正確使用。解析請(qǐng)求獲取隨機(jī)數(shù)范圍并將生產(chǎn)的結(jié)果以格式返回。在代碼的最后，我們會(huì)在合法的參數(shù)返回內(nèi)生成隨機(jī)數(shù)并將結(jié)果返回給客戶端。雖然示例很簡(jiǎn)單，但是它已經(jīng)包含了使用構(gòu)建的基本流程解析請(qǐng)求，設(shè)置狀態(tài)碼，返回響應(yīng)數(shù)據(jù)。

在介紹了那么多 Express 核心概念之后，接下來(lái)的文章將會(huì)把注意力放在如何構(gòu)建一個(gè)真實(shí)的應(yīng)用上。這里我們先從構(gòu)建應(yīng)用 API 接口開(kāi)始。從某種程度上來(lái)說(shuō)幾乎所有的軟件應(yīng)用其背后都是由一組強(qiáng)大的 API 驅(qū)動(dòng)。

其實(shí) API 就是一種代碼之間交互的一種方式，它既可以是在程序內(nèi)部也可以是通過(guò)網(wǎng)絡(luò)的跨機(jī)器進(jìn)行。例如，Express 中的 app.use 和 app.get 就屬于在內(nèi)部使用 API 。而通過(guò) HTTP 或者 FTP 等協(xié)議發(fā)送 JSON、XML 數(shù)據(jù)的方式則屬于后者。對(duì)于后一種方式需要注意的是，API 的提供者和使用者必須對(duì)數(shù)據(jù)格式做出約定。在本文示例中，我們將會(huì)討論如何使用 Express 構(gòu)建后一類型的 API 接口，同時(shí)所有 HTTP 接口返回的數(shù)據(jù)格式都將使用 JSON。

另外，本章還會(huì)討論如何設(shè)計(jì)一個(gè)優(yōu)雅的 API 用于提升使用者的體驗(yàn)和效率，讓 API 的含義一目了然而不用去閱讀又臭又長(zhǎng)的說(shuō)明文檔。就像“好代碼”與“壞代碼”一樣，API 是否優(yōu)雅其實(shí)更多的取決于實(shí)際情形。盲目遵循 API 設(shè)計(jì)的最佳實(shí)踐有時(shí)會(huì)顯得很迂腐，因?yàn)樗锌赡芘c使用者的期望不一致。

接下來(lái)的內(nèi)容包括：

什么是 API 。

Express 中構(gòu)建 API 的基礎(chǔ)內(nèi)容。

HTTP 方法與應(yīng)用邏輯的關(guān)聯(lián)。

多版本 API 的實(shí)現(xiàn)和管理。

HTTP 狀態(tài)碼的正確使用。

首先，我們需要明確該示例的功能以及 API 的使用方式，后面再寫(xiě)代碼。

假設(shè)，現(xiàn)在程序需要在接受到 America/Los_Angeles 或 Europe/London 等代表時(shí)區(qū)的字符串后，返回該時(shí)區(qū)的當(dāng)前時(shí)間信息（例如：2015-04-07T20:09:58-07:00 ）。該返回信息與現(xiàn)實(shí)中易懂的時(shí)間格式是不一樣的，因?yàn)樗菫橛?jì)算機(jī)設(shè)計(jì)的。

通過(guò)類似下面格式的 URL 的 HTTP 請(qǐng)求來(lái)調(diào)用應(yīng)用 API：

/timezone?tz=America+Los_Angeles

而服務(wù)端 API 返回的 JSON 的數(shù)據(jù)格式，如下：

{
    "time": "2015-06-09T16:20:00+01:00",
    "zone": "America/Los_Angeles"
}

只要能調(diào)用 API 并對(duì) JSON 數(shù)據(jù)進(jìn)行解析，你就可以在任意平臺(tái)構(gòu)建任意應(yīng)用程序。如下圖，你可以通過(guò) AJAX 請(qǐng)求該 API 實(shí)現(xiàn)一個(gè)展示時(shí)區(qū)信息的單頁(yè)應(yīng)用。

你也可以利用該接口實(shí)現(xiàn)下圖所示的移動(dòng)應(yīng)用。

你甚至可以利用該 API 實(shí)現(xiàn)下圖一樣的終端命令行工具：在終端中打印服務(wù)端 API 接口返回的數(shù)據(jù)。

像前一章的天氣應(yīng)用一樣，我們可以利用這些 API 返回的冰冷數(shù)據(jù)構(gòu)建更具表達(dá)力的 UI 。

了解 API 概念之后，下面我們就動(dòng)手實(shí)現(xiàn)一個(gè) Express 驅(qū)動(dòng)的 API 服務(wù)。實(shí)現(xiàn)的原理非常簡(jiǎn)單：通過(guò)中間件和內(nèi)置函數(shù)解析網(wǎng)絡(luò)請(qǐng)求并將 JSON 數(shù)據(jù)和 HTTP 狀態(tài)碼封裝到響應(yīng)對(duì)象并返回給客戶端。

從技術(shù)角度上說(shuō)，API 服務(wù)除了使用 JSON 格式外，你還可以是使用 XML 或者純文本。但是 Express 和 JavaScript 對(duì) JSON 的支持是最好的，同時(shí)它也是當(dāng)前最流行的格式，所以后面會(huì)一直使用 JSON 作為默認(rèn)數(shù)據(jù)格式。

下面我們編寫(xiě)一個(gè)為多平臺(tái)提供隨機(jī)數(shù)生成的服務(wù)，該 API 將擁有如下特性：

在請(qǐng)求 API 時(shí)必須附帶隨機(jī)數(shù)最小值和最大值。

解析請(qǐng)求獲取隨機(jī)數(shù)范圍并將生產(chǎn)的結(jié)果以 JSON 格式返回。

你可能認(rèn)為這里完全可以使用純文本來(lái)替換 JSON 格式。但是發(fā)送 JSON 數(shù)據(jù)是開(kāi)發(fā)者的必備技能，而且 JSON 格式極易拓展。

該工程的構(gòu)建步驟如下：

新建 package.json 。

創(chuàng)建工程主入口文件 app.js 。

在 app.js 中創(chuàng)建應(yīng)用和路由中間件。

首先，在新建的 package.json 中，復(fù)制下面的內(nèi)容并按照依賴項(xiàng)：

{
    "name": "random-number-api",
    "private": true,
    "scripts": {
        "start": "node app"
    },
    "dependencies": {
        "express": "^5.0.0" 
    }
}

接下來(lái)，將下面的代碼復(fù)制到入口文件 app.js 中：

var express = require("express");
var app = express();

app.get("/random/:min/:max", function(req, res) {
    var min = parseInt(req.params.min);
    var max = parseInt(req.params.max);
    if (isNaN(min) || isNaN(max)) {
        res.status(400);
        res.json({ error: "Bad request." });
        return;
    }
   
    var result = Math.round((Math.random() * (max - min)) + min);
    res.json({ result: result });
});

app.listen(3000, function() {
    console.log("App started on port 3000");
});

現(xiàn)在啟動(dòng)應(yīng)用并訪問(wèn) http://localhost:3000/random/... 的話，你將看到一個(gè)附帶 10 ～ 100 范圍內(nèi)隨機(jī)數(shù)的 JSON 數(shù)據(jù)。

接下來(lái)，我們來(lái)分析上面的代碼。

與之前一樣，前兩行代碼引入了 Express 并創(chuàng)建了一個(gè) Express 應(yīng)用實(shí)例。

然后，我們創(chuàng)建了一個(gè)路由中間件用于處理類似 /random/10/100 這樣的 API 請(qǐng)求。當(dāng)然，這里還存在一些 bug ，例如，沒(méi)有過(guò)濾掉 /random/foo/bar 請(qǐng)求。所以，在調(diào)用 API 的時(shí)候請(qǐng)確保使用的參數(shù)是整型變量。

在然后，我們使用內(nèi)置的 parseInt 解析范圍參數(shù)，而該函數(shù)的返回值只可能是整形數(shù)字或者 NaN。如果傳入的參數(shù)有一個(gè)為 NaN 的話就會(huì)給客戶端返回一個(gè)錯(cuò)誤信息。下面這部分代碼對(duì)于整個(gè)程序來(lái)說(shuō)是非常重要的：

if (isNaN(min) || isNaN(max)) {
  res.status(400);
  res.json({ error: "Bad request." });
  return;
}

如果上面的參數(shù)檢查的結(jié)果是最少有一個(gè)為 NaN ，程序就會(huì)進(jìn)行如下處理：

設(shè)置 HTTP 狀態(tài)碼為 400。常見(jiàn)的 404 錯(cuò)誤就是它的一個(gè)具體變種，表示的含義是：用戶請(qǐng)求的出現(xiàn)了問(wèn)題。

發(fā)送包含錯(cuò)誤信息的 JSON 數(shù)據(jù)。

結(jié)束請(qǐng)求處理并跳出中間件執(zhí)行。

在代碼的最后，我們會(huì)在合法的參數(shù)返回內(nèi)生成隨機(jī)數(shù)并將結(jié)果返回給客戶端。

雖然示例很簡(jiǎn)單，但是它已經(jīng)包含了使用 Express 構(gòu)建 API 的基本流程：解析請(qǐng)求，設(shè)置 HTTP 狀態(tài)碼，返回響應(yīng)數(shù)據(jù)。你可以在這個(gè)基礎(chǔ)之上構(gòu)建更為復(fù)雜優(yōu)雅的 API 。

CURD 是對(duì)程序中 Create、Read、Update、Delete 四種業(yè)務(wù)動(dòng)作的一個(gè)簡(jiǎn)稱。

大多數(shù)的應(yīng)用都會(huì)涉及到 CURD 操作。例如，對(duì)于一個(gè)圖片分享應(yīng)用來(lái)說(shuō)，其中涉及圖片的所有操作就是典型的 CRUD：

用戶上傳照片的行為對(duì)應(yīng)就是 create 操作。

用戶瀏覽照片的行為就是 read 操作。

用戶更新照片的行為就是 update 操作。

用戶刪除照片的行為就是 delete 操作。

無(wú)論是分享照片的社交應(yīng)用還是文件存儲(chǔ)服務(wù)，你生活中的使用的很多服務(wù)中都使用了這種模式。不過(guò)在開(kāi)始討論構(gòu)建 CRUD 功能的 API 之前，我們先來(lái)看看被稱為 HTTP 方法的內(nèi)容。

HTTP 的規(guī)范中是這樣定義其方法的：

HTTP 方法明確了對(duì)請(qǐng)求 URI 所標(biāo)識(shí)資源進(jìn)行的操作，而且方法是區(qū)分大小寫(xiě)的。

一個(gè)更易理解的解釋是：客戶端在發(fā)送 HTTP 請(qǐng)求時(shí)需要指定一個(gè) HTTP 方法，然后服務(wù)端回依據(jù)不同的 HTTP 方法做出不同的響應(yīng)。雖然，可用的 HTTP 方法有很多，但是常用的其實(shí)并不多。其中在 Web 應(yīng)用中常用是下面 4 個(gè)：

GET 是最常用的一個(gè) HTTP 方法，它表示請(qǐng)求服務(wù)端資源。例如，加載網(wǎng)站首頁(yè)、請(qǐng)求圖片資源都使用的是 GET。雖然服務(wù)端的響應(yīng)可能不同，但是GET 請(qǐng)求并不會(huì)改變服務(wù)器的資源。例如，對(duì)某圖片資源的一次或者多次請(qǐng)求并不會(huì)導(dǎo)致圖片本身出現(xiàn)任何差別。

POST 是另一個(gè)常用的 HTTP 方法。例如，創(chuàng)建新博客、上傳照片、注冊(cè)用戶、清空購(gòu)物車等業(yè)務(wù)都是使用 POST 。與 GET 不同的是：每次 POST 請(qǐng)求都會(huì)導(dǎo)致服務(wù)端發(fā)生修改。

PUT 方法用于對(duì)已有記錄的修改，所有我覺(jué)得它應(yīng)該被稱為 "UPDATE" 更為合適。例如，修改博客標(biāo)題、修改用戶昵稱等操作都是 PUT 操作。另外，PUT 還具備 POST 的功能：就是當(dāng)要修改的記錄不存在時(shí)可以進(jìn)行新建操作（非必需）。其次 PUT 還具有 GET 方法的特點(diǎn)：對(duì)同一 URL 的一次或多次 PUT 請(qǐng)求后的結(jié)果是一致的。

DELETE 方法用于記錄刪除。例如，刪除用戶文章、刪除網(wǎng)絡(luò)照片。另外，與 PUT 一樣同一刪除請(qǐng)求無(wú)論是執(zhí)行一次還是多次最終結(jié)果是一致的。

雖然 HTTP 還有很多其他的方法，但是它們?cè)诂F(xiàn)實(shí)開(kāi)發(fā)過(guò)程中并不常見(jiàn)。理論上你甚至可以只使用 GET 和 POST 請(qǐng)求完成所有業(yè)務(wù)，但是這是錯(cuò)誤實(shí)踐畢竟它違反了 HTTP 規(guī)范也會(huì)給開(kāi)發(fā)者造成困惑。另外，很多瀏覽器也是根據(jù) HTTP 方法來(lái)明確所執(zhí)行的操作類型。所以，即使并沒(méi)有強(qiáng)制你也應(yīng)該參照該規(guī)范來(lái)約束自己的行為。

前面你已經(jīng)見(jiàn)過(guò) Express 中對(duì)部分方法的處理，不過(guò)下面的代碼將一次涵蓋上面所有的四個(gè)方法：

var express = express("express");
var app = express();

app.get("/", function(req, res) {
  res.send("you just sent a GET request, friend");
});

app.post("/", function(req, res) {
  res.send("a POST request? nice");
});

app.put("/", function(req, res) {
  res.send("i don"t see a lot of PUT requests anymore");
});

app.delete("/", function(req, res) {
  res.send("oh my, a DELETE??");
});

app.listen(3000, function() {
  console.log("App is listening on port 3000");
});

將代碼復(fù)制到入口文件 app.js 中并啟動(dòng)服務(wù)，然后你就可以使用 cURL 命令測(cè)試不同的 HTTP 方法了。默認(rèn)情況下 cURL 使用 GET 發(fā)送請(qǐng)求，但是你可以使用 -X 選項(xiàng)來(lái)指定其他的方法。例如，curl -X PUT http://localhost:3000 。

回想以下之前的照片分享應(yīng)用，下面是其中可能的 CRUD 操作：

用戶上傳圖片，此為 Create。

用戶瀏覽圖片，此為 Read。

用戶更新圖片備注等信息，此為 Update。

用戶從站點(diǎn)刪除圖片，此為 Delete。

不難看出 CRUD 操作與之前四種 HTTP 方法存在對(duì)應(yīng)關(guān)系：

Create = POST

Read = GET

Update = PUT

Delete = DELETE

因此通過(guò)這四個(gè) HTTP 方法我們可以很好的實(shí)現(xiàn)最常見(jiàn) CRUD 風(fēng)格的 web 應(yīng)用程序。

實(shí)際上對(duì)于更新和創(chuàng)建動(dòng)作與 HTTP 方法的對(duì)應(yīng)關(guān)系，一些人有著自己的看法。它們認(rèn)為 PUT 更應(yīng)該對(duì)應(yīng)創(chuàng)建動(dòng)作而非 POST。另外，新的 PATCH 方法則對(duì)應(yīng)更新操作。雖然本文將會(huì)使用上面那種更規(guī)范的對(duì)應(yīng)關(guān)系，但是你完全可以按照自己的意愿選擇。

為了應(yīng)對(duì)未來(lái)可能的 API 更新，對(duì) API 進(jìn)行版本控制是一件非常高效的方法。例如，前面獲取指定時(shí)區(qū)當(dāng)前時(shí)間的 API 在推出后就被很多的廠商和開(kāi)發(fā)者使用。但是，幾年幾后由于某些原因必須對(duì)該 API 進(jìn)行更新而與此同時(shí)你又不能影響之前的使用者。此時(shí)，我們就可以通過(guò)添加新版本來(lái)解決這個(gè)問(wèn)題。其中原有的 API 請(qǐng)求可以通過(guò)：

/v1/timezone

而新版本 API 請(qǐng)求則可以使用：

/v2/timezone

這樣不僅在進(jìn)行 API 更新時(shí)防止了代碼的破壞性更改。而且接口使用者也有了更靈活的選擇，他們可以在必要的時(shí)候進(jìn)行 API 切換。

在 Express 中可以使用 Router 中間件來(lái)實(shí)現(xiàn) API 版本管理?？截愊旅娲a到文件 app1.js 中，并講其作為第一個(gè)版本 API 的實(shí)現(xiàn)：

var express = require("express");
var api = express.Router();

api.get("/timezone", function(req, res) {
    res.send("Sample response for /timezone");
});
api.get("/all_timezones", function(req, res) {
    res.send("Sample response for /all_timezones");
});

module.exports = api;

請(qǐng)注意，上面的中間件代碼在處理的 URL 并沒(méi)有包含 /v1 。下面在入口文件中引入這個(gè) Router 中間件并進(jìn)行路由映射。

var express = require("express");
var apiVersion1 = require("./api1.js");
var app = express();
app.use("/v1", apiVersion1);
app.listen(3000, function() {
    console.log("App started on port 3000");
});

然后，你將最新版本的 API 實(shí)現(xiàn)放在 api2.js 文件中：

var express = require("express");
var api = express.Router();

api.get("/timezone", function(req, res) {
    res.send("API 2: super cool new response for /timezone");
});
module.exports = api;

最后，通過(guò) Router 將這兩個(gè)版本的 API 同時(shí)添加到主入口中：

var express = require("express");

var apiVersion1 = require("./api1.js");
var apiVersion2 = require("./api2.js");
var app = express();

app.use("/v1", apiVersion1);
app.use("/v2", apiVersion2);
app.listen(3000, function() {
    console.log("App started on port 3000");
});

你可以通過(guò)瀏覽器驗(yàn)證這些版本化后的 API 是否正確工作，另外你也可以使用 cURL 命令進(jìn)行測(cè)試。

就像前面章節(jié)介紹的那樣，Router 可以讓你將不同的路由存放在不同文件中進(jìn)行管理。而版本化 API 就是最典型的應(yīng)用實(shí)例。

每一個(gè) HTTP 響應(yīng)都應(yīng)該附帶一個(gè) HTTP 狀態(tài)碼，其中最有名的就是 404 Not Found 。

雖然 404 是最出名的，但是 200 狀態(tài)碼確是最常見(jiàn)的。與 404 不同的是，雖然當(dāng)網(wǎng)頁(yè)成功加載或 JSON 數(shù)據(jù)成功返回后都會(huì)包含狀態(tài)碼 200，但它并不會(huì)被展示出來(lái)。

當(dāng)然，除了 404 和 200 之外，HTTP 中還定義了很多其他的狀態(tài)碼，包括 100、200、300、400 以及 500 系列。需要注意的是并不是每個(gè)系列中所有 100 個(gè)數(shù)字都有明確定義，例如，100 系列只有 100，101，102 三個(gè)有效碼，緊跟其后就是 200 。

每個(gè)狀態(tài)碼系列其實(shí)都有特定的含義和主題，總結(jié)就是：

1xx: 成功接收到請(qǐng)求。
2xx: 成功
3xx: 重定向
4xx: 客戶端錯(cuò)誤
5xx: 服務(wù)端錯(cuò)誤

規(guī)范中只定義的大約 60 個(gè)狀態(tài)碼。你可以在此基礎(chǔ)上拓展自己的狀態(tài)碼，但是通常并不會(huì)這么做。因?yàn)閮?yōu)秀的 API 的首要設(shè)計(jì)原則就是確保不會(huì)對(duì)使用者造成任何歧義，所以應(yīng)該最大程度遵循官方規(guī)范的指導(dǎo)。后面我們會(huì)對(duì)上面的每個(gè)區(qū)間的狀態(tài)碼進(jìn)行講解，但是在此之前先來(lái)看看如何在 Express 中設(shè)置狀態(tài)碼。

少部分應(yīng)用還在使用 HTTP 1.0 版本的協(xié)議，而大部分以及切換到了 1.1 版本。作為下一個(gè)版本的 HTTP 2.0 標(biāo)準(zhǔn)現(xiàn)在也逐漸在推廣過(guò)程中。幸運(yùn)的是，2.0 版本的協(xié)議大部分更新都在底層所以切換時(shí)并不會(huì)涉及太大的工作量。另外，2.0 版本還新增了一個(gè) 421 的狀態(tài)碼。

默認(rèn)情況下，HTTP 狀態(tài)碼是 200。如果用戶訪問(wèn)的 URL 對(duì)應(yīng)資源不存在的話，Express 會(huì)發(fā)送 404 錯(cuò)誤。如果訪問(wèn)的服務(wù)器出現(xiàn)問(wèn)題的話，Express 就會(huì)發(fā)送 500 錯(cuò)誤。

但是這些都是 Express 的默認(rèn)行為，某些情形下可能會(huì)需要自行設(shè)置狀態(tài)碼。為此，Express 的 response 對(duì)象提供了一個(gè) status 方法，你需要在調(diào)用是傳入對(duì)應(yīng)狀態(tài)碼就能完成設(shè)置。

// ...
res.status(404);
// ...

該方法可以進(jìn)行鏈?zhǔn)秸{(diào)用，所以你可以緊跟其后使用 json 設(shè)置返回的數(shù)據(jù)。

res.status(404).json({ error: "Resource not found!" });
// 它等價(jià)于：
res.status(404);
res.json({ error: "Resource not found!" });

雖然 Express 對(duì)原生 Node 的 response 對(duì)象進(jìn)行了拓展，并且在使用 Express 時(shí)也應(yīng)遵循 Express 風(fēng)格，但是你依舊可以使用原生方法來(lái)完成設(shè)置。

res.statusCode = 404;

100 區(qū)間的官方狀態(tài)碼只有兩個(gè)：100（繼續(xù)） 和 101 （切換協(xié)議），而且它們很少會(huì)被用到。如果你必須處理的話，可以去官網(wǎng)或者維基上查看。

200 區(qū)間狀態(tài)碼表示請(qǐng)求成功。雖然該區(qū)間狀態(tài)碼不少，但是常用的也就下面 4 個(gè)：

200：作為最常見(jiàn)的狀態(tài)碼，它也被稱為 "OK"。這意味著請(qǐng)求和響應(yīng)都正確執(zhí)行期間并沒(méi)有出現(xiàn)任何錯(cuò)誤或者重定向操作。

201：與 200 十分類似，但是使用情形略有不同。它通常用于 POST 或者 PUT 請(qǐng)求成功創(chuàng)建記錄后。例如，創(chuàng)建博文、上傳圖片等操作成功后就會(huì)發(fā)送 201。

202：202 是 201 的一個(gè)變種。因?yàn)?，資源的創(chuàng)建大多是異步進(jìn)行的，而這些操作也是費(fèi)時(shí)的。所以，你可以在此時(shí)給客戶端響應(yīng) 202 。它表示已經(jīng)成功接收數(shù)據(jù)正在等待創(chuàng)建。

204：它表示用戶刪除請(qǐng)求所對(duì)應(yīng)的資源并不存在已經(jīng)被刪除過(guò)了。

同樣，在 300 區(qū)間，我們只介紹其中常用的三個(gè)，并且它們?nèi)忌婕爸囟ㄏ颉?/p>

301：它表示所訪問(wèn)資源位置已經(jīng)發(fā)生修改，請(qǐng)?jiān)L問(wèn)最新的 URL 。通常它還會(huì)附帶一個(gè) Location 的頭部信息指明重定向的位置。

303：它表示請(qǐng)求的資源已經(jīng)創(chuàng)建完成，現(xiàn)在你就會(huì)被重定位到一個(gè)新頁(yè)面。

307：與 301 類似都是提示當(dāng)前 URL 不存在。不過(guò)區(qū)別是，301 的重定向是永久的而 307 可能重定向的只是一個(gè)臨時(shí)性 URL 。

400 區(qū)間的狀態(tài)碼是最多的，而它通常都是表示由于客戶端的錯(cuò)誤導(dǎo)致請(qǐng)求失敗。

401 和 403：這兩個(gè)狀態(tài)碼分別表示“未授權(quán)”和“禁止”。字面上看兩者很類似，但是前者可能表示用戶未登錄而后者則可能是用戶登錄了但是權(quán)限不夠。

404：它表示用戶 URL 請(qǐng)求的資源并不存在。

至于該區(qū)間其他狀態(tài)碼，讀者可以去維基上自行查看，這里就不一一介紹了。另外，當(dāng)你不確定應(yīng)該使用哪種客戶端錯(cuò)誤狀態(tài)碼時(shí)，你可以直接使用 400 。

作為 HTTP 規(guī)范里的最后一個(gè)區(qū)間，500 區(qū)間狀態(tài)碼表示的是服務(wù)內(nèi)部出現(xiàn)錯(cuò)誤。例如，請(qǐng)求過(guò)載或者數(shù)據(jù)庫(kù)連接中斷。另外，理論上該區(qū)間的錯(cuò)誤只能有服務(wù)內(nèi)部自己觸發(fā)。最后，為了防止黑客窺探太多內(nèi)部信息，你可以對(duì)所有的內(nèi)部錯(cuò)誤僅僅返回一個(gè)抽象的“內(nèi)部服務(wù)器錯(cuò)誤”這樣的信息。

本章包含的內(nèi)容有：

使用 Express 構(gòu)建 API 服務(wù)。

HTTP 方法以及與 CRUD 操作之間的關(guān)系。

如果對(duì) API 進(jìn)行版本控制，提示服務(wù)的兼容性和穩(wěn)定性。

HTTP 狀態(tài)碼的使用和其意義。

原文地址