REST 和 API 有什么區別？

Question

我想知道REST和API之間的主要區別。有時我在編程文檔中看到REST API，那么REST或API與8834142818316308551821688相同嗎？ 我想知道更多關於 REST、API 和 REST API 之間的關系。

Answer 1

REST 是一種 API。 並非所有 API 都是 REST，但所有 REST 服務都是 API。

API 是一個非常廣泛的術語。 通常這是一段代碼如何與另一段代碼對話。 在 Web 開發中，API 通常指的是我們從在線服務中檢索信息的方式。 API 文檔將為您提供 URL 列表、查詢參數和其他有關如何從 API 發出請求的信息，並告知您將為每個查詢提供什么樣的響應。

REST 是一組關於如何構建 Web API 的規則/標准/指南。 由於有很多方法可以做到這一點，擁有一個商定的構建 API 的系統可以節省構建 API 時做出決策的時間，並節省理解如何使用 API 的時間。

其他流行的 API 范例包括 SOAP 和 GraphQL。

Answer 2

REST 主要是指按照預期的方式使用 HTTP 協議。 對 URL 使用GET HTTP 方法來檢索信息，可能基於 HTTP Accept標頭采用不同的格式。 使用POST HTTP 方法在服務器上創建新項目，使用PUT編輯現有項目，使用DELETE刪除它們。 使 API 具有冪等性，即使用相同的信息重復相同的查詢應該產生相同的結果。 以層次結構等方式構建您的 URL。

REST 只是如何使用 URL 和 HTTP 協議來構建 API 的指導原則。 它沒有說明返回格式，也可能是 JSON。

例如，這與將二進制或 XML 消息發送到指定端口的 API 完全相反，根本不使用 HTTP 方法或 URL 的差異。

Answer 3

REST 和 API 沒有可比性，REST 是一種 API 類型。

一般來說，API 是一組部署在應用程序軟件上的協議，用於與其他軟件組件（如瀏覽器與服務器交互）進行通信，並為應用程序軟件提供給多個實時消費者的服務提供接口。

Rest 是 API 遵循的一種原則形式，其中服務器提供客戶端希望與服務交互的任何信息。

Answer 4

REST 基本上是一種管理客戶端和服務器行為的 Web 架構風格。 API 是一組更通用的協議，部署在軟件上以幫助它與其他一些軟件進行交互。 REST 僅面向 Web 應用程序。 並且主要處理 HTTP 請求和響應。 這使得它實際上可以被任何編程語言使用並且易於測試。

Answer 5

API基本上是一組函數和過程，允許一個應用程序訪問另一個應用程序的功能

REST 是一組用於構建 Web API 的規則或指南。 它基本上是網絡上的網絡應用程序的架構風格，僅限於基於客戶端-服務器的應用程序。

閱讀更多信息： https : //www.freelancinggig.com/blog/2018/11/02/what-is-the-difference-between-api-and-rest-api/

Answer 6

API 是Application Programming Interface的首字母縮寫詞，它定義了一組必須實現的結構（即類），以便與公開 API 的服務進行交互。 API 通常公開可以調用的操作，包括任何必需或支持的參數以及預期的響應。 此處的經典示例是 Java 生態系統中的 Corba IDL、SOAP 或 RMI，以及 Swagger 或 OpenAPI 等文檔中指定的 Web 系統的類似 RPC 用法。

相反，REST（REpresentational State Transfer）是 Fielding 在他的博士論文中指定的，他分析了整個用戶交互如何在 Web 上發生。 他意識到在 Web 上只需要一個傳輸協議、一個東西的命名方案以及一個明確定義的交換格式來交換消息或文檔。 因此，這三個部分定義了與此類生態系統中的對等方交互的接口。 傳輸層由 HTTP 覆蓋，而命名方案由 URI/IRI 定義。 與通常只支持一種語法的傳統 RPC 協議相反，REST 實際上獨立於特定的語法。 為了保持互操作性，客戶端和服務器都需要進行協商，HTTP 本身通過Accept請求和Content-Type響應標頭支持這一點。 只要客戶端和服務器支持 HTTP、URI/IRI 和一組由支持超媒體的媒體類型定義的協商表示格式，它們就能夠相互交互。 因此，在更狹義的意義上，REST 除了 HTTP、URI/IRI 和相應的媒體類型之外沒有其他 API。

然而，不幸的是事情並沒有那么容易。 不幸的是，大多數人對REST或REST API理解非常不同。 雖然 URI 本身不應該傳達任何語義，畢竟它們只是指向資源的指針，但許多程序員認為 URI 的重要性比他們應有的要高。 一些客戶端 ie 會嘗試從 URI 中提取一些知識，或者考慮使用 URI 來返回代表某種類型的響應。 即，考慮使用諸如https://api.acme.org/users/1的 URI 來返回描述該特定系統的特定用戶的表示似乎很自然。 外部文檔可能會指定返回遵循給定模板的 JSON 結構，例如

{
  "id": 1,
  "firstName": "Roman",
  "lastName": "Vottner",
  "role": "Admin",
  ...
}

然而，可以預料，這樣的事情更接近於 RPC 而不是 REST。 響應既不是 REST 所要求的自描述性的，也不是遵循明確定義的媒體類型的表示格式，該媒體類型定義了語法和可能形成消息的每個元素。 因此，客戶端通常是為一個特定系統（或 REST API，如果您願意）量身定制的，並且不能在沒有進一步手動集成/更新的情況下用於與開箱即用的不同系統進行交互。 OpenAPI 或 Swagger 等外部文檔用於描述可用的端點、服務器將能夠處理的有效負載模板以及預期的響應，具體取決於輸入。 因此，這些文檔是真實的，因此定義了客戶端可以查找甚至用於自動生成存根類以與服務器端交互的 API，類似於 SOAP。

因此，我不同意戴夫給出的答案。 雖然對於 RPC 系統或REST API的通用理解術語，他的定義可能是合適的，但對於實際的 REST 架構，他的解釋根本不合適，因此，至少 IMO 也不正確。 REST 不是規則、標准和/或指南的集合。 它是一組少數約束，可以確保此類架構中的對等方避免耦合，支持未來的演進並變得更加健壯以應對變化。

Answer 7

我通過這個（鏈接到他解釋差異的那部分）視頻了解了 API 和 REST API 之間的區別。