什麼是 RESTful API？
RESTful API 是一種能讓兩個電腦系統用來安全地透過網際網路交換資訊的介面。大多數商業應用程式必須與其它內部和第三方應用程式溝通，以執行各種任務。舉例來說，為了產生每月薪資單，您的內部帳戶系統必須與您客戶的銀行系統共用資料，以自動化提供薪資單的過程，並且與內部出勤卡應用程式進行通訊。多種 RESTful API 支援此類資訊交換，因為它們遵守安全、可靠、且有效率的通訊標準。
什麼是 API？
應用程式介面 (API) 定義了與其他軟體系統通訊時必須遵循的規則。開發人員公開或建立 API，以便其他應用程式能夠以程式設計方式與其應用程式通訊。例如，時間表應用程式公開一個 API，要求提供員工的全名和日期範圍。收到此資訊後，它會在內部處理員工的時間表，並傳回該日期範圍內的工作時數。
您可以將 Web API 視為用戶端和 Web 上資源之間的閘道。
用戶端
用戶端是指希望從 Web 存取資訊的使用者。用戶端可以是使用 API 的人或軟體系統。例如，開發人員可以編寫從天氣系統存取天氣資料的程式。或者，您可以在直接瀏覽天氣網站時，從瀏覽器存取相同的資料。
資源
資源是指不同應用程式向其用戶端提供的資訊。資源可以是影像、影片、文字、數字或任何類型的資料。將資源提供給用戶端的機器也稱為伺服器。組織使用 API 共用資源並提供 Web 服務，同時維護安全、控制和身分驗證。此外，API 協助他們確定哪些用戶端可以存取特定的內部資源。
什麼是 REST？
Representational State Transfer (REST) 是一種軟體架構，它對 API 的運作方式施加了條件。REST 最初是作為管理複雜網路 (如網際網路) 上的通訊指導方針而建立。您可以使用以 REST 為基礎的架構，來支援大規模的高效能和可靠的通訊。您可以輕鬆實作和修改，為任何 API 系統提供可視性和跨平台可移植性。
API 開發人員可以使用若干不同的架構來設計 API。遵循 REST 架構風格的 API 稱為 REST API。實作 REST 架構的 Web 服務稱為 RESTful Web 服務。術語 RESTful API 通常是指 RESTful Web API。但是，您可以互換使用術語 REST API 和 RESTful API。
以下是 REST 架構風格的一些原則：
統一介面
統一介面是任何 RESTful Web 服務設計的基礎。它指示伺服器以標準格式傳輸資訊。格式化資源在 REST 中稱為呈現。這種格式可以不同於伺服器應用程式上資源的內部呈現。例如，伺服器可以將資料存放為文字，但以 HTML 呈現格式傳送。
統一介面強加了四個架構約束：
- 請求應識別資源。他們透過使用統一的資源識別符來執行此操作。
- 用戶端可以根據需要，在資源呈現中具有足夠的資訊來修改或刪除資源。伺服器透過傳送進一步描述資源的中繼資料，來滿足此條件。
- 用戶端接收有關如何進一步處理呈現的資訊。伺服器透過傳送包含用戶端如何充分利用其中繼資料的自我描述訊息來實作這一點。
- 用戶端接收有關完成任務所需的所有其他相關資源的資訊。伺服器透過在呈現中傳送超連結來實作，以便用戶端可以動態探索更多資源。
無狀態
在 REST 架構中，無狀態是指伺服器獨立於所有之前的請求，完成每個用戶端請求的通訊方法。用戶端可以按任何順序請求資源，並且每個請求都為無狀態，或與其他請求隔離。這種 REST API 設計約束意味著伺服器每次都能完全理解並滿足請求。
分層系統
在分層系統架構中，用戶端可以連線至用戶端與伺服器之間的其他授權中介，而且仍然會接收來自伺服器的回應。伺服器還可以將請求傳遞至其他伺服器。您可以將 RESTful Web 服務設計為在若干多層 (如安全性、應用程式和業務邏輯) 伺服器上執行，共同協同以滿足用戶端請求。這些層對用戶端仍然不可見。
可快取性
RESTful Web 服務支援快取，這是在用戶端或中介裝置上存放某些回應以改善伺服器回應時間的程序。例如，假設您瀏覽的網站在每個頁面具有共同的頁首和頁尾影像。每次您瀏覽新的網站頁面時，伺服器都必須重新傳送相同的影像。為了避免此情況，用戶端在第一次回應後快取或存放這些影像，然後直接使用快取中的影像。RESTful Web 服務透過使用將自身定義為可快取或不可快取的 API 回應來控制快取。
隨需編碼
在 REST 架構風格中，伺服器可透過將軟體程式設計碼傳輸至用戶端，以臨時擴展或自訂用戶端功能。例如，當您在任何網站上填寫註冊表單時，您的瀏覽器會立即反白顯示您犯的任何錯誤，如錯誤的電話號碼。由於伺服器傳送的程式碼，它可以執行此操作。
RESTful API 有哪些優勢？
RESTful API 包含以下優勢：
可擴展性
由於 REST 最佳化用戶端-伺服器互動，因此實作 REST API 的系統可有效擴展。由於伺服器不必保留過去的用戶端請求資訊，因此無狀態消除了伺服器負載。管理完善的快取部分或完全消除了一些用戶端-伺服器互動。所有這些功能均支援可擴展性，而不會導致降低效能的通訊瓶頸。
靈活性
RESTful Web 服務支援完全的用戶端-伺服器分離。這些服務簡化並解耦各種伺服器元件，以便每個部分都能獨立演進。伺服器應用程式的平台或技術變更不會影響用戶端應用程式。分層應用程式功能能夠進一步提高靈活性。例如，開發人員可以在不重寫應用程式邏輯的情況下，對資料庫層進行變更。
獨立性
REST API 獨立於使用的技術。您可以使用各種程式設計語言來編寫用戶端和伺服器應用程式，而不會影響 API 設計。您還可以在不影響通訊的情況下，變更任一端的基礎技術。
RESTful API 是如何運作的？
RESTful API 的基本功能與瀏覽網際網路相同。用戶端在需要資源時，使用 API 來聯絡伺服器。API 開發人員在伺服器應用程式 API 文件中，闡述了用戶端應如何使用 REST API。以下是任何 REST API 呼叫的一般步驟：
- 用戶端向伺服器傳送請求。用戶端按照 API 文件，以伺服器能理解的方式格式化請求。
- 伺服器對用戶端進行身分驗證，並確認用戶端有權發出該請求。
- 伺服器接收請求並在內部處理。
- 伺服器向用戶端傳送回應。回應包含告知用戶端請求是否成功的資訊。該回應還包含用戶端請求的任何資訊。
REST API 請求和回應詳細資訊視乎 API 開發人員設計 API 的方式略有差異。
RESTful API 用戶端請求包含哪些內容？
RESTful API 需要請求包含以下主要元件：
唯一資源識別符
伺服器使用唯一資源識別符來識別每個資源。針對 REST 服務，伺服器通常使用統一資源定位器 (URL) 來執行資源識別。URL 指定資源的路徑。URL 類似於您在瀏覽器中輸入的網站地址，以瀏覽任何網頁。URL 也稱為請求端點，清晰地向伺服器指定用戶端需要什麼。
方法
開發人員通常使用超文字傳輸協定 (HTTP) 來實作 RESTful API。HTTP 方法告知伺服器需要對資源做什麼。以下是四種常見的 HTTP 方法：
GET
用戶端使用 GET 來存取位於伺服器上指定 URL 的資源。他們可以快取 GET 請求，並在 RESTful API 請求中傳送參數，以指示伺服器篩選資料後再傳送。
POST
用戶端使用 POST 向伺服器傳送資料。其包含請求中的資料呈現。多次傳送相同 POST 請求的連帶結果是，具有多次建立相同資源的。
PUT
用戶端使用 PUT 更新伺服器上的現有資源。與 POST 不同，在 RESTful Web 服務中多次傳送相同的 PUT 請求會得到相同的結果。
DELETE
用戶端使用 DELETE 請求來移除資源。DELETE 請求可變更伺服器狀態。但是，如果使用者沒有適當的身分驗證，則請求會失敗。
HTTP 標頭
請求標頭是用戶端與伺服器之間交換的中繼資料。例如，請求標頭會指示請求和回應的格式，提供有關請求狀態的資訊等。
資料
REST API 請求可能包含 POST、PUT 和其他 HTTP 方法成功運作的資料。
參數
RESTful API 請求可包含參數，為伺服器提供更多關於需要做什麼的詳細資訊。以下是一些不同類型的參數：
- 指定 URL 詳細資訊的路徑參數。
- 請求更多資源相關資訊的查詢參數。
- 快速驗證用戶端的 Cookie 參數。
什麼是 RESTful API 身分驗證方法？
RESTful Web 服務必須先對請求進行身分驗證，才能傳送回應。身分驗證是驗證身分的程序。例如，您可以出示身分證或駕照來證明您的身分。同樣，RESTful 服務用戶端必須向伺服器證明其身分以建立信任。
RESTful API 有四種常見的身分驗證方式：
HTTP 身分驗證
HTTP 定義了一些身分驗證方案，您可以在實作 REST API 時直接使用這些方案。以下是其中兩個方案：
基本身分驗證
在基本身分驗證中，用戶端在請求標頭中傳送使用者名稱和密碼。它使用 base64 進行編碼，這是一種編碼技術，可將一對程式碼轉換為 64 個字元集以進行安全傳輸。
承載者身分驗證
術語「承載者身分驗證」是指對字元承載者進行存取控制的程序。承載者字符通常是伺服器為回應登入請求而產生的加密字串。用戶端在請求標頭中傳送字符以存取資源。
API 金鑰
API 金鑰是 REST API 身分驗證的另一個選項。在這種方法中，伺服器將唯一產生的值指派給首次使用的用戶端。每當用戶端嘗試存取資源時，它都會使用唯一的 API 金鑰來自行驗證。API 金鑰的安全性降低，因為用戶端必須傳輸金鑰，這使其容易遭受網路盜竊。
OAuth
OAuth 將密碼與字符相結合，以實現對任何系統高度安全的登入存取。伺服器首先會請求一個密碼，然後要求額外的字符來完成授權程序。它可以隨時檢查字符，還能隨時間推移以特定範圍和使用壽命來檢查字符。
RESTful API 伺服器回應包含哪些內容？
REST 原則要求伺服器回應包含以下主要元件：
狀態行
狀態行包含一個三位數狀態碼，用於傳達請求成功或失敗。例如，2XX 碼指示成功，而 4XX 和 5XX 碼則指示錯誤。3XX 碼指示 URL 重新引導。
以下是一些常見的狀態碼：
- 200：一般成功回應
- 201：POST 方法成功回應
- 400：伺服器無法處理的錯誤請求
- 404：找不到資源
郵件正文
回應正文包含資源呈現。伺服器根據請求標頭包含的內容，來選擇適當的呈現格式。用戶端可以請求 XML 或 JSON 格式的資訊，這些格式定義了資料如何以純文字形式寫入。例如，如果用戶端請求名稱為 John 的人名和年齡，則伺服器會傳回 JSON 呈現，如下所示：
'{"name":"John", "age":30}'
標頭
回應還包含有關回應的標頭或中繼資料。它們提供有關回應的更多關聯內容，並包含伺服器、編碼、日期和內容類型等資訊。
AWS 如何協助您進行 RESTful API 管理？
Amazon API Gateway 是一種全受管服務，可讓開發人員輕鬆地建立、發佈、維護、監控和保護任何規模的 API。使用 API Gateway 時，您可以建立 RESTful API，以啟用即時雙向通訊應用程式︰
使用 API Gateway，您可以：
- 為使用者提供 API 請求和回應的高速效能。
- 利用 AWS Identity and Access Management (IAM) 和 Amazon Cognito，授與對 API 的存取權，兩者均提供原生 OAuth 支援。
- 使用 API Gateway 同時執行相同 API 的多個版本，快速重複執行、測試和發行新的版本。
- 透過 API Gateway 監控有關 API 呼叫、資料延遲和錯誤率的效能指標和資訊。
