API概念與通訊協定

tags: RD1

目錄

• API概念與通訊協定
  • API是什麼
    • 什麼是 API？
  • WebService
    • 規則:
    • 好處:
    • API WebService 比較
  • Restful
    • REST ( REpresentational State Transfer )
    • HTTP Method
    • 如何設計路由？
    • 路由語義化：RESTful 風格應用
    • SOAP REST 比較
  • 通訊協定是什麼
    • 何謂『協定』（Protocol）
    • OSI 模式
    • 網路層
    • 網際網路協定 IP (The Internet Protocol)：
    • 傳輸控制協定 TCP (Transmission Control Protocol)
    • TCP UDP比較
    • 網際網路位址 (Internet Address)
    • 網域名稱 (Domain Name)
  • HTTP STATUS
    • 資訊回應 (Informational responses, 100–199)
    • 成功回應 (Successful responses, 200–299)
    • 重定向 (Redirects, 300–399)
    • 用戶端錯誤 (Client errors, 400–499)
    • 伺服器端錯誤 (Server errors, 500–599)
  • 參考資料

API是什麼

API全文是
Application Programming Interface
應用程式介面

在看下面解釋之前 可以先這個影片

什麼是 API？

推薦的api開放網頁 apilist

WebService

Web Services是一種軟體元件，它透過Web 通訊協定及資料格式的開放式標準(例如 HTTP、XML 及 SOAP等)來為其他的應用程式提供服務。

在構建和使用Web Service時,主要用到以下幾個關鍵的技術和

規則:

1. XML:描述資料的標準方法.
2. SOAP:表示資訊交換的協議.
3. SDL:描述一個Web Services的運作方式，以及指示用戶端與它可能的互動方式。
4. UDDI:提供註冊與搜尋Web Service資訊的一個標準。

好處:

1. 互操作性：Web Service允許應用程式之間進行通信，交換數據和共享服務。
2. 可用性：Web Service的功能可以從簡單的信息查找到複雜的算法計算。
3. 可重用性：Web Service之間可以相互組合，以提供更為複雜的服務，由於其互操作性的特點，可以輕鬆的在其他的服務中重用Web Service組件,提高了服務的重用率。
4. 易於部署：Web Service可以部署在基於Internet標準的容器中，如Apache、Axis2等，以提供HTTP或者WSDL（網絡服務定義語言）驅動的服務。
5. 成本低：Web Service是通過打包成Web服務組件進行部署，從而降低了使用的成本。

API WebService 比較

API	WebService
所有Web API都不是Web Service	所有Web Service都是Web API
支持的內容更多，如：URL,Request/Response/Header,Cache,Version等	僅支持HTTP協議，透過WSDL定義接口
可使用任何類型的通訊方式	僅使用SOAP，REST和XML-RPC三種方式通訊
是一個輕量型架構	需要使用SOAP協議並透過網路來收發資料，是一個重量型架構
為開放式的，任何可以解析JSON、文本、HTML或者XML的客戶端都可以使用	不是開放式的，但可以被任何可以解析XML文檔的客戶端使用
可以依存於應用程序或IIS中	只能託管在IIS中

Restful

REST ( REpresentational State Transfer )

簡單地說 REST 是一種軟體架構風格 ，適合應用在複雜的網路服務環境中，然而 HTTP 也是符合 REST 的架構的一項實作。

目前有很多著名的 Web Service 都是遵循 REST 的理念進行設計，像是 Amazon AWS, eBay, Facebook, Yahoo Web Service, Google Web Service 等等。

此段文章引用自表現層狀態轉換

1. 伺服器/客戶端分離（Client-Server）

客戶端-伺服器結構限制的目的是將客戶端和伺服器端的關注點分離. 將使用者介面所關注的邏輯和資料儲存所關注的邏輯分離開來有助於提高使用者介面的跨平台的可移植性.通過簡化伺服器模組也有助於伺服器模組的可延伸性。

2. 無狀態（Stateless）

伺服器不能儲存客戶端的資訊, 每一次從客戶端傳送的請求中，要包含所有的必須的狀態資訊，對談資訊由客戶端儲存，伺服器端根據這些狀態資訊來處理請求.

伺服器可以將對談狀態資訊傳遞給其他服務，比如資料庫服務，這樣可以保持一段時間的狀態資訊，從而實現認證功能。

當客戶端可以切換到一個新狀態的時候傳送請求資訊。當一個或者多個請求被傳送之後，客戶端就處於一個狀態變遷過程中，每一個應用的狀態描述可以被客戶端用來初始化下一次的狀態變遷。

3. 分層

客戶端一般不知道是否直接連接到了最終的伺服器，或者是路徑上的中間伺服器。中間伺服器可以通過負載均衡和共享快取的機制提高系統的可延伸性,這樣可也便於安全策略的部署。

4. 可快取

如同全球資訊網一樣，客戶端和中間的通訊傳遞者可以將回覆快取起來。回覆必須明確的或者間接的表明本身是否可以進行快取，這可以預防客戶端在將來進行請求的時候得到陳舊的或者不恰當的資料。管理良好的快取機制可以減少客戶端-伺服器之間的互動，甚至完全避免客戶端-伺服器互動，這進一步提了高效能和可延伸性。

5. 統一操作介面

這是 RESTful 系統設計的基本出發點. 它簡化了系統架構, 減少了耦合性, 可以讓所有模組各自獨立的進行改進. 包括下列四個限制:

• 請求中包含資源的 ID (Resource identification in requests)

  請求中包含了各種獨立資源的標識, 例如, 在 Web 服務中的 URIs. 資源本身和傳送給客戶端的標識是獨立. 例如, 伺服器可以將自身的資料庫資訊以 HTML XML 或者 JSON 的方式傳送給客戶端, 但是這些可能都不是伺服器的內部記錄方式.

• 資源通過標識來操作 (Resource manipulation through representations)

  當客戶端擁有一個資源的標識, 包括附帶的元資料, 則它就有足夠的資訊來刪除這個資源.

• 訊息的自我描述性 (Self-descriptive messages)

  每一個訊息都包含足夠的資訊來描述如何來處理這個資訊. 例如, 媒體類型 (midia-type) 就可以確定需要什麼樣的剖析器來分析媒體資料.

• 用超媒體驅動應用狀態 (Hypermedia as the engine of application state (HATEOAS))

  同用戶存取 Web 伺服器的 Home 頁面相似,當一個 REST 客戶端存取了最初的 REST 應用的 URI 之後, REST 客戶端應該可以使用伺服器端提供的連結,動態的發現所有的可用的資源和可執行的操作.隨著存取的進行, 伺服器在回應中提供文字超連結, 以便客戶端可以得到當前可用的操作. 客戶端無需用確定的編碼的方式記錄下伺服器端所提供的動態應用的結構資訊.

朝著這樣的理念所設計出來的系統可稱為 RESTful

HTTP Method

此段文章引用自網際網路 (Internet) 與 TCP/IP 通訊協定

• GET 讀取資源
• PUT 替換資源
• PATCH 更換資源部分內容
• DELETE 刪除資源
• POST 新增資源
• OPTIONS 回傳該資源所支援的所有 HTTP 請求方法
• CONNECT 將連線請求轉換至 TCP/IP 隧道

如何設計路由？

我們會採用一套 REST 的架構風格來設計路由，RESTful 的設計以「資源」為中心，再搭配 HTTP method 的動詞，以及 CRUD 等資料操作：

對資料的操作，不外乎：新增 (create)、讀取 (read)、更新 (update)、刪除 (delete) 四種動作，通常會簡稱為 CRUD。

而 HTTP method 是有意義的動詞，如 GET、POST、PATCH、DELETE 等，因此 RESTful 的表意設計運用動詞的組合，來表達出對資源的操作方式。

例如我們看到 GET http://www.example.com/posts/1，就會立刻可以理解他要取得 www.example.com 網站中，編號 1、名為 posts 的資源。

路由語義化：RESTful 風格應用

什麼是 RESTful

運用 HTTP 來表達語義的路由設計風格稱為 RESTful API。所謂的 API 是應用程式介面 (application programming interface)，網址也是一種應用程式的「介面」，故稱為 API。

RESTful 風格的網址設計強調從路由結構就能看出要對什麼資料、進行什麼操作。舉例來說，如果資料是 todos，那麼 RESTful 風格的 CRUD 路由就會這樣寫：

從網址上，你會看出要操作的資源叫做 todos，這邊習慣用複數名詞。然後固定結構是：

• 瀏覽全部資料：GET + 資源名稱
• 瀏覽特定資料：GET + 資源名稱 + :id
• 新增一筆資料：POST + 資源名稱
• 修改特定資料：PUT + 資源名稱 + :id
• 刪除特定資料：DELETE + 資源名稱 +

總之，如果需要處理特定資料，就需要加上 :id，其他情況都用 HTTP 動詞來做變化。從網址上的複數名詞可以看出操作的對象，這就是 RESTful 的精神。

當然，一個專案裡不可能所有的路由都在操作資料，因此不會每條路由都能完美對齊 RESTful，例如「登入」的路由通常設定為 POST /login，就完全是以動詞為中心。身為專案的架構者，有時候還是需因地制宜，風格只是參考，不是阻礙。

舉個例子，我們在專案中實際的配置可能是

下圖對照了「完全採用 RESTful 風格」 和實際的路由規劃做對照，用 * 標記出了不同的地方。

• new 頁面和 edit 頁面：這兩條路由並不是「對 todos 進行資料操作」，但也是很常出現的頁面。因為本質仍然是瀏覽，所以動詞用 GET，另外在 URL 加上 new 和 edit 來表達功能屬性。
• 首頁 v.s. 瀏覽全部路由：在這裡我們選擇著重了首頁的語義，因此只配置路由 GET /，而沒有配置 GET /todos。

如果是部落格網站，可能會有叫做 posts 的資源，再搭配 HTTP 動詞和新增／瀏覽／修改／刪除等操作，就會出現如下變化：

RESTful 的網址變化很有規律，也很簡潔，因此近年有愈來愈多人採用 RESTful 設計風格來架構網站，

注意，它是風格，而不是標準，意思是偶爾出現特例沒關係

SOAP REST 比較

SOAP	REST
SOAP是一種傳輸協議	REST是一種架構風格
SOAP不能與REST交互，因為SOAP是一種協議	REST可以使用SOAP Web Service,因為REST是一種架構風格,可以使用任何的Web協議,如HTTP,SOAP
SOAP只允許使用XML數據格式	REST允許使用多種數據格式,如JSON、文本、HTML和XML等
SOAP需要佔用的帶寬更多	REST需要的帶寬資源較少
SOAP比REST更可靠	REST安全性沒有SOAP高
SOAP比REST慢	REST比SOAP快
SOAP可以自行實施對數據安全控制,自由度更高	REST嚴重依賴傳輸層的安全控制
SOAP支持SMTP和HTTP協議	REST只需要使用HTTP協議

通訊協定是什麼

何謂『協定』（Protocol）

此段文章引用自網際網路 (Internet) 與 TCP/IP 通訊協定

所謂的『Protocol』是指在網路上一種可以彼此溝通的模式，雙方都要依照某些規則進行溝通，其實有點像一個國家裡會有很多方言，但是如果大家都哇啦哇啦的各講各的，彼此無法溝通，所以一定會規定一個語言是「國語」，大家遵循著某種語法及某個規則，彼此溝通。例如你講客家話，我講閩南話，但是我們彼此聽不懂所以無法溝通，但我們找出了我們都會的語言叫國語，這樣我們就彼此了解對方的意思了。

OSI 模式

此段文章引用自何謂通訊協定

應用層 (Application)
表現層 (Presentation)
會談層 (Session)
傳輸層 (Transport)

網路層 (Network)
資料連接層 (Data Link)
實體層 (Physical)

有四層是屬于使用者功能範圍的﹐不過它們也常常會被整合在一起。您要記住的一點是﹕無論程式設計者如何定義這些協定﹐(例如﹐把它們分為兩層或四層)﹐這四層在實際上都會被執行的。

應用層

它定義了應用程式是如何進入OSI模式進行傳送。

它自己並不屬于應用程式﹐但它支持使用者的應用程式﹐如﹕檔案傳送﹑密碼驗證﹑和網路工具等。

表現層

在這層﹐定義了數據的語法(syntax)﹑變更﹑和格式。當應用程式的語法和格式都不同的時候﹐這層還將定義了如何翻譯這些不同。

會談層

這層定義了如何連接和掛斷連接﹐和在網路上面的數據如何交換。

傳輸層

在這層﹐將會設定節點地址的傳達﹐還有錯誤檢測和修正的方法。

網路層

這層就好比是一個中間人界乎於網絡功能和使用者功能之間。它會定義出封包在網路中移動的路由和其處理過程﹐這層還決定了網路是如何進行管理功能的﹐比如﹐發送狀態信息給接點和規範封包的流動等。

一個有趣的事情是﹐網路層還能將底層協定(網路功能)對上層協定(使用者功能)躲起來。這樣﹐在網路的使用者就可以使用不同種類的硬體了。這是非常好的事情﹐假如您用來建網的材料都不盡相同的話。

資料連接層

在這層指定了要採用的信息單元(message unit)是什麼﹐(通常在LAN上面的信息單元被稱為packet或frame)﹐以及它們的格式﹑和如何通過網絡。每一個packet都會被賦予一個地址碼和偵錯監測值(checksum)。有一個Binary synchronous communications協定﹐會判定出一個封包如果在丟失的情況下﹐要等待多久會被重新發送﹐這個協定也是在這層裡面定義。

總體來說﹐這層的工作就是保證一個無錯誤的物理上的數據傳輸。

實體層

在這層裡面您必須作出一些機械和電子方面的決定﹐也就是要定義出在終端和網絡之間要使用的設備。同時﹐採用何種佈線也要在這裡決定出來。

網際網路協定 IP (The Internet Protocol)：

此段文章引用自網際網路 (Internet) 與 TCP/IP 通訊協定

定義網際網路中最基本的服務：將資料串經由路徑的選擇(routing) 送達目的地。IP 的封包中定義一串資料以及一個地址，如此該封包就可以在網路上選擇路徑，試著將資料送到目的地去，IP 封包中並沒有定義任何錯誤偵測的資料，因此根據收到的 IP 封包並沒有辦法發現資料是否發生錯誤，更嚴重的是當 IP 封包中的位址資料錯誤時，該封包會被送往一個錯誤的目的機器，因此 IP 通訊協定基本上不保證封包一定會送到目的地。同樣的道理， IP 封包中也沒有記載一整組資料封包間相對的順序資料。IP 通訊協定中規定：IP 封包依照 "盡其所能" 的原則，由來源主機送往目的主機，途中經過的每一個路由器 (router) 都必須根據 IP 封包中之目的地位址來選擇封包的前進路線,直到傳送到目的主機為止。

傳輸控制協定 TCP (Transmission Control Protocol)

TCP 的目的是保證無錯誤的大量資料傳輸、並提供錯誤偵測、復原以及排序資訊，以補 IP 通訊協定之不足。

TCP UDP比較

	TCP	UDP
連結特性	可靠的連接導向	非可靠的連接導向
速度	慢	快
穩定度	高	低
握手程序	需要	不需要
優點	可靠的傳輸機制	傳輸量大、迅速
缺點	速度較慢	不可靠、應用程式需自行提供可靠機制

網際網路位址 (Internet Address)

此段文章引用自網際網路 (Internet) 與 TCP/IP 通訊協定

在 IP (Internet Protocol) 通訊協定中，每一台機器有一個四個位元組 (4 bytes) 的網路位址，例如：140.121.196.50 或是 140.121.81.16，用來區辨每一台機器，每一個資料封包中都有來源機器以及目的機器的 IP 位址。

網域名稱 (Domain Name)

一般的人都很討厭去記數字，尤其是像上面這樣子的四個連續的數字只代表一部機器，如果一次要記下十台機器的位址的話，那該如何是好呢?

舉例來說，並不是每個人都知道 "24622192" 所代表的意義，但是 "海洋大學的電話號碼" 是不是也代表相同的意義呢? 你很輕鬆地說 "撥海洋大學的電話" ，是不是比說 "撥 24622192" 要簡單呢? 查電話號碼的動作留給 104 查號台去做嘛!

在 IP 位址上也是這樣子的，我們用所謂的 DNS 這樣子的分散式網域位址資料庫來記錄及查詢任何一串 IP 位址，例如：cs.ntou.edu.tw 這個網域名稱經過查詢 DNS 之後，得到 140.121.196.50 這一連串的數字，從此以後我們可以記憶 cs.ntou.edu.tw 這樣子的網域名稱來存取該主機了。

DNS 具有階層式的架構，例如 tw 網域下有 edu, com, org, gov, … 等等子網域，edu.tw 子網域下又分為 ntu, nctu, ntou, … 各個子網域，ntou.edu.tw 子網域下又分為 cs, ee, na, … 各個子網域，在上面任何一個子網域可以代表一個主機也可以是一堆主機。

HTTP STATUS

此段文章引用自HTTP 狀態碼

資訊回應 (Informational responses, 100–199)

• 100 Continue
  此臨時回應表明，目前為止的一切完好，而用戶端應當繼續完成請求、或是在已完成請求的情況下，忽略此資訊。

• 101 Switching Protocol
  此狀態碼乃為用戶端 Upgrade 請求標頭發送之回應、且表明伺服器亦切換中。

• 102 Processing (WebDAV)
  此狀態碼表明伺服器收到並處理請求中，但目前未有回應。

• 103 Early Hints
  此狀態碼主要與 Link 標頭有關：它能讓用戶代理（user agent）能在伺服器準備回應前能 preloading 資源。

成功回應 (Successful responses, 200–299)

• 200 OK
  請求成功。成功的意義依照 HTTP 方法而定：
  GET：資源成功獲取並於訊息主體中發送。
  HEAD：entity 標頭已於訊息主體中。
  POST：已傳送訊息主體中的 resource describing the result of the action。
  TRACE：伺服器已接收到訊息主體內含的請求訊息。

• 201 Created
  請求成功且新的資源成功被創建，通常用於 POST 或一些 PUT 請求後的回應。

• 202 Accepted
  此請求已經被接受但尚未處理。此狀態為非承諾性，代表 HTTP 無法在之後傳送一個非同步的回應告知請求的處理結果。最初目的為外部程序或其他伺服器處理請求的情況，或用於批次處理中。

• 203 Non-Authoritative Information
  此回應碼表示回傳的中介資料集與並非與原始伺服器上的有效確定集合完全相同，而是來自本地或第三方的副本。除此情況外，200 OK 回應碼應該被優先使用。

• 204 No Content
  There is no content to send for this request, but the headers may be useful. The user-agent may update its cached headers for this resource with the new ones.

• 205 Reset Content
  This response code is sent after accomplishing request to tell user agent reset document view which sent this request.

• 206 Partial Content
  This response code is used because of range header sent by the client to separate download into multiple streams.

• 207 Multi-Status (WebDAV)
  A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate.

• 208 Multi-Status (WebDAV)
  Used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.

• 226 IM Used (HTTP Delta encoding)
  The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.

重定向 (Redirects, 300–399)

• 300 Multiple Choice
  請求擁有一個以上的回應。用戶代理或使用者應該從中選一。不過，並沒有標準的選擇方案。

• 301 Moved Permanently
  此回應碼的意思是，請求資源的 URI 已被改變。有時候，會在回應內給予新的 URI。

• 302 Found
  This response code means that URI of requested resource has been changed temporarily. New changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.

• 303 See Other
  Server sent this response to directing client to get requested resource to another URI with an GET request.

• 304 Not Modified
  This is used for caching purposes. It is telling to client that response has not been modified. So, client can continue to use same cached version of response.

• 305 Use Proxy
  在舊版本的 HTTP 規範中，表示請求資源必須透過代理存取。基於對代理的頻內設置 (in-band configuration) 相關的安全考量，該狀態碼已棄用。

• 306 unused
  該狀態碼已不再被使用，僅被保留。該狀態碼曾在先前得的 HTTP 1.1 規範中被使用。

• 307 Temporary Redirect
  伺服器發送此回應來使客戶端保持請求方法不變向新的地址發出請求。 與 302 Found 相同，差別在於客戶端不許變更請求方法。例如，應使用另一個 POST 請求來重複發送 POST 請求。

• 308 Permanent Redirect
  This means that the resource is now permanently located at another URI, specified by the Location: HTTP Response header. This has the same semantics as the 301 Moved Permanently HTTP response code, with the exception that the user agent must not change the HTTP method used: if a POST was used in the first request, a POST must be used in the second request.

用戶端錯誤 (Client errors, 400–499)

• 400 Bad Request
  此回應意味伺服器因為收到無效語法，而無法理解請求。

• 401 Unauthorized
  需要授權以回應請求。它有點像 403，但這裡的授權，是有可能辦到的。

• 402 Payment Required
  此回應碼留作未來使用。一開始此碼旨在用於數位交易系統，然而，目前極少被使用，且不存在標準或慣例。

• 403 Forbidden
  用戶端並無訪問權限，例如未被授權，所以伺服器拒絕給予應有的回應。不同於 401，伺服端知道用戶端的身份。

• 404 Not Found
  伺服器找不到請求的資源。因為在網路上它很常出現，這回應碼也許最為人所悉。

• 405 Method Not Allowed
  伺服器理解此請求方法，但它被禁用或不可用。有兩個強制性方法：GET 與 HEAD，永遠不該被禁止、也不該回傳此錯誤碼。

• 406 Not Acceptable
  This response is sent when the web server, after performing server-driven content negotiation, doesn't find any content following the criteria given by the user agent.

• 407 Proxy Authentication Required
  This is similar to 401 but authentication is needed to be done by a proxy.

• 408 Request Timeout
  This response is sent on an idle connection by some servers, even without any previous request by the client. It means that the server would like to shut down this unused connection. This response is used much more since some browsers, like Chrome, Firefox 27+, or IE9, use HTTP pre-connection mechanisms to speed up surfing. Also note that some servers merely shut down the connection without sending this message.

• 409 Conflict
  表示請求與伺服器目前狀態衝突

• 410 Gone
  This response would be sent when requested content has been deleted from server.

• 411 Length Required
  伺服器拒絕該請求，因為 Content-Length 頭沒有被定義，然而伺服器要求。

• 412 Precondition Failed
  The client has indicated preconditions in its headers which the server does not meet.

• 413 Payload Too Large
  請求的實體資料大小超過了伺服器定義的上限，伺服器會關閉連接或返回一個 Retry-After 回應頭。

• 414 URI Too Long
  客戶端的 URI 請求超過伺服器願意解析的長度。

• 415 Unsupported Media Type
  被請求資源的多媒體類型不被伺服器支援，因此該請求被拒絕。

• 416 Requested Range Not Satisfiable
  The range specified by the Range header field in the request can't be fulfilled; it's possible that the range is outside the size of the target URI's data.

• 417 Expectation Failed
  This response code means the expectation indicated by the Expect request header field can't be met by the server.

• 418 I'm a teapot
  The server refuses the attempt to brew coffee with a teapot.

• 421 Misdirected Request
  The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.

• 422 Unprocessable Entity (WebDAV)
  The request was well-formed but was unable to be followed due to semantic errors.

• 423 Locked (WebDAV)
  被訪問的資源被鎖定。

• 424 Failed Dependency (WebDAV)
  由於先前的請求失敗導致此請求失敗。

• 426 Upgrade Required
  The server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server sends an Upgrade header in a 426 response to indicate the required protocol(s).

• 428 Precondition Required
  The origin server requires the request to be conditional. Intended to prevent the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.

• 429 Too Many Requests
  用戶在給定的時間內 ("rate limiting") 發送了過多的請求。

• 431 Request Header Fields Too Large
  伺服器不願意處理該請求，因為標頭欄位過大。該請求可能可以在減少請求標頭欄位大小後重新提交。

• 451 Unavailable For Legal Reasons
  用戶端請求違法的資源，例如受政府審查的網頁。

伺服器端錯誤 (Server errors, 500–599)

• 500 Internal Server Error
  伺服器端發生未知或無法處理的錯誤。

• 501 Not Implemented
  The request method is not supported by the server and cannot be handled. The only methods that servers are required to support (and therefore that must not return this code) are GET and HEAD.

• 502 Bad Gateway
  This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.

• 503 Service Unavailable
  The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. Note that together with this response, a user-friendly page explaining the problem should be sent. This responses should be used for temporary conditions and the Retry-After: HTTP header should, if possible, contain the estimated time before the recovery of the service. The webmaster must also take care about the caching-related headers that are sent along with this response, as these temporary condition responses should usually not be cached.

• 504 Gateway Timeout
  This error response is given when the server is acting as a gateway and cannot get a response in time.

• 505 HTTP Version Not Supported
  請求使用的 HTTP 版本不被伺服器支援。

• 506 Variant Also Negotiates
  The server has an internal configuration error: transparent content negotiation for the request results in a circular reference.

• 507 Insufficient Storage
  The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.

• 508 Loop Detected (WebDAV)
  The server detected an infinite loop while processing the request.

• 510 Not Extended
  Further extensions to the request are required for the server to fulfill it.

• 511 Network Authentication Required
  The 511 status code indicates that the client needs to authenticate to gain network access.

參考資料

API? IPA? 應用程式介面是什麼? API種類介紹 | What is API? REST? SOAP?【電腦說人話】

Web Services介紹

正確甄別API、REST API、RESTful API和Web Service之間的異同

什麼是REST? 認識 RESTful API 路由語義化設計風格

何謂通訊協定

網際網路 (Internet) 與 TCP/IP 通訊協定

何謂通訊協定？

表現層狀態轉換

HTTP 狀態碼