REST是API還是：REST vs Java接口？

我和一位同事討論過，他真的很喜歡REST，但我仍然需要確信好處。REST是API還是：REST vs Java接口？

我的主要問題是，從消費應用程序的角度來看，我並不真正將REST看作API或接口。讓我詳細說明一下。我們有兩個使用RESTful API調用另一個的應用程序。這是使用JAX-RS和RESTeasy實現的。儘管使用RESTeasy，但基於接口生成REST客戶端也很簡單。

所以我們假設這是一個處理書籍和作者的系統。應用程序需要知道一本書，讓我們假設它已經知道一些ID。

在休息，它會調用例如http://server/book/21，得到返回的任意有效載荷和它deserialise爲Book對象。
使用RESTeasy客戶端，我們有一個接口BookService，方法爲Book getBook(int bookId)，我們只需調用getBook(21)並返回一個Book對象。

我想說明的一點是，BookService是一個定義良好的接口，在那裏你（作爲程序員）可以很容易地看到，它期望的參數是一個標識符，它會返回一個Book對象。使用「僅REST」，我們訪問某個URL，並且返回任意數據。沒有明確定義的接口，您不知道如何在不知道服務器內部URL信息的情況下如何構建URL，並且您必須「手動」解析XML（希望使用XSD）。

另一件事。我提到了書籍和作者。

當使用接口時，您可以只有BookService返回Book s和AuthorService返回Author s。 A Book可能有一個屬性authorId，你可以通過調用Author getAuthor(int authorId)得到一個Author對象。

使用REST時，您可以調用書籍URL並返回有關作者的一些信息，包括作者鏈接。然後，您可以按照鏈接獲取有關作者的更多信息。但是，您如何知道究竟在哪裏找到這個鏈接？和以前相同的問題出現了：如何構建鏈接，我如何知道如何解析返回數據？

當混合兩者時，可能會發生奇怪的事情。如果我想通過id得到一個Book，我可能會調用BookService（內部轉換爲REST調用），並獲得一個很好的Book對象。但是，如果我想獲得作者信息，我有這String authorLink，我必須遵循以獲得我的Author對象。但相反，當我的出發點是Author並使用AuthorService檢索它時，我得到作者寫入的指向書對象的字符串（URL）集合的鏈接。

那麼爲什麼REST會考慮API？爲什麼我應該比REST更好地定義（Java）接口？我如何混合兩者？

來源

2012-09-17 pbean

那你最終會一起去？ – bryanmac

在您選擇的搜索引擎上檢出Hypermedia APIs。

有一些很好的文獻，將解釋你如何「知道」什麼要調用什麼請求。特別是HATEOS。

爲何選擇超媒體API？ REST是一個相當寬鬆和淡化的術語。通常執行不正確。最近有一股潮流來試圖澄清這種混亂，因此是「新」術語。如果正確完成，您將獲得REST（參見超媒體API）服務的強大功能，您可以使用Java/.NET中使用強類型化服務（ala SOAP，RPC）的熟悉樣式界面來訪問

來源

2012-09-17 21:41:23 Finglas

+1 - 關於超媒體的後續閱讀（後續文章到這一篇）：http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http – bryanmac

其他鏈接：http： //blog.steveklabnik.com/posts/2012-02-23-rest-is-over – bryanmac

@bryanmac Steve的東西非常值得一讀。很好也跟隨在twitter上鍊接到其他人做的東西。 – Finglas

REST不是一個API，而是更多的架構。 REST用於通過現有的HTTP協議在2個不同的系統之間進行通信。 REST對很多事情都很有意義，也許在你的情況下你不需要使用它。

來源

2012-09-17 21:43:13 noisewaterphd

沒有人按照Roy Fielding的設想使用REST，無論出於何種原因。所以這是不切實際的。對於懶惰的人來說，這足以不必考慮它。

顯然這個行業很癡迷於爲RPC創造不同的名字。

來源

2012-09-17 21:58:33 irreputable

簡而言之，REST API對於其他編程語言是靈活的。

我不熟悉RESTEasy，但熟悉RESTful服務。 REST沒有標準。大多數REST服務發佈如何與其REST API進行交互。哪些URL（資源）可用，要發送的內容類型以及將返回的類型。好的也會發布返回的http狀態碼以及如何處理錯誤。在你的情況下，我想知道REST Easy客戶端在做什麼。它只是將API調用轉換爲HTTP請求並處理開發人員的一切？

我們記錄了我們的REST API調用並提供了包含所有模型的jar文件。模型使用JAXB註釋，因此開發人員不需要知道從服務返回的XML或JSON的所有信息。那就是如果他們使用Java和我們的模型。發佈和記錄API的好處在於，其他語言的開發人員可以使用提供HTTP請求的服務。這使得開發人員可以用幾乎所有的編程語言開發客戶端應用（最近似乎是更多的C＃實現）。

除了提供模型的jar文件之外，我們在非Java開發人員的文檔中提供了XSD。

來源

2012-09-17 22:08:59 km1

如果您考慮關於構建分佈式應用程序/系統的工具的REST（體系結構而非設計或編碼風格），而不是使用衆所周知的且經過驗證的概念（在萬維網上）管理應用程序狀態的主要意圖，感覺在某些情況下使用它。

當您想要將某些處理/計算從一個應用程序移動到某個遠程主機時（例如，檢索書籍列表），您可以通過將您的方法調用（GetBooks）序列化爲SOAP消息來完成該操作，然後將該消息添加到HTTP請求等。或者你可以直接調用GET/books。在某些情況下，使用第二種方法要便宜得多。如果我提到資源緩存是基礎設施的一部分，而不是顯式實現的資源緩存或靈活性，當您需要相同資源的不同表示時，它甚至會更有意義。

如果某些服務使用REST風格並仔細編寫（與任何API類似），則易於理解和使用。這些類型的服務也可以很容易地從不同類型的客戶端（javascript，php，..）中消費，其中沒有像JAX-WS或WCF這樣的框架。

爲簡化起見，您可以將REST服務視爲書架，從中可以獲得一些書籍（資源），您可以在其中發佈新書或放置一本書。如果每個資源在問題域方面都有意義，並且資源表示包含指向相關資源的鏈接，那麼我不會看到理解/使用它的問題。

來源

2012-09-17 22:35:20

你誤會REST的重要組成部分。在精心設計的RESTful系統中，有兩兩件事必須非常有據可查：

的入口點（或「酷」的URI），您使用開始與系統的有效載荷數據交互
架構請求中發送並在響應中返回（HTTP術語，這些都是媒體類型）

給我只是這兩件事情，我將能夠建立一個客戶到您的RESTful API。從＃1開始，使用＃2的知識來找到我的系統API「超鏈接」的方法，我將能夠找到我需要的資源。

瞭解您系統的Book表示形式將允許我進行GET調用以檢索並理解它，或者創建一個POST或PUT調用。 HTTP支持那些開箱即用的動詞，我只需要知道通過線路發送了什麼（並且＃2告訴了我）。

如果我不喜歡XML，我可以嘗試要求服務器，如果我能代替說話JSON和HTTP支持那種內容協商的開箱即用。

REST是不是獨角獸作出魔仙塵，也不會僅僅憑藉所使用的解決您的問題。然而，它卻是一種常識性的架構，它試圖利用現有的久經考驗，易於理解，可擴展和靈活的技術和方法。

來源

2012-09-18 01:54:07

ReST是一種架構風格，而不是一個API。

一些優勢你開始使用REST

多重響應型能力（例如：JSON，XML）作息不綁定到XML像SOAP
使用JSON，使你的體重負荷輕，你的服務速度更快
更輕鬆地開發和測試
其餘部分使用普通HTTP，所以沒有代理相關的問題

關於服務定義，你可以爲你的REST服務，以查看完整的選項生成的wadl文件。大多數服務器自動生成這些。這些服務需要記錄在SOAP或ReST中。你可以檢查LinkedIn ReST API。

我看到的SOAP的唯一優點是SOAP可以提供的安全功能。但並非所有的應用都需要這種安全級別。

來源

2012-09-18 11:12:47 basiljames

REST是API還是：REST vs Java接口？

回答

相關問題