Thrift作爲REST的公共API替代品嗎？

我開始爲我正在處理的新網站創建一個API。Thrift作爲REST的公共API替代品嗎？

我最初想讓它成爲一個普通的REST API，但我一直在想如何能夠在一個批處理中編譯多個客戶端庫的節儉。

Thrift是公共API，套接字和所有的可行選項，還是應該堅持使用REST？

如果REST創建多個客戶端庫最好的方法是什麼，或者我只需要弄髒並且實際寫入它們？

否則，如果Thrift，我會編譯庫，只是提供下載鏈接或簡單地給開發人員.thrift文件來生成自己的庫？

注意：它仍然是一個小型站點，所以我將創建僅用於API的Thrift規範文件。

2012-04-06 Johann du Toit

這取決於：*誰*將連接和*如何*？（就我個人而言，我發現ProtocolBuffers更好更好設計，即使沒有「標準」* RPC *服務器。對於更復雜的RPC，也有類似ICE的東西，但是，* who *將連接和* how * ？） – 2012-04-06 00:52:46

因此，在Google Buffers中，我仍然可以定義對象類型，序列化並通過http發送。就像是JSON的替代品，但具有客戶期望的定義類型？在PHP中有這方面的經驗嗎？ – 2012-04-06 00:55:55

Protocol Buffers是一個二進制序列化協議，與Thrift非常相似。（Thrift只是一個「全合一」的軟件包，因爲它還包含了服務端點實現。）支持ProtocolBuffers中的RPC端點，因爲[RPC支持被設計爲]（https://developers.google.com/protocol-buffers/docs/proto#services），但沒有「標準」服務器實現。但是，有些項目提供了適當的RPC端點。 – 2012-04-06 02:26:36

首先，REST和Thrift是橙子的蘋果 - 前者是一般風格，後者是特定的二進制RPC系統。

但是對於公共接口，我認爲使用標準文本格式（通常是JSON或XML）的REST更有意義;因爲從任何語言或平臺訪問都比較容易;儘管在許多平臺上都有Thrift客戶端，但仍然有更多的工作要做。它還強制客戶端使用特定的訪問方式，幾乎不得不使用特定的Thrift客戶端庫。

所以問題寧願是你究竟想要獲得什麼？你覺得那裏「酷」到底是什麼？如果你只是想玩新技術，那沒什麼問題，但是你應該先玩，然後看看它是否有意義。

來源

2012-04-12 00:18:23 StaxMan

只是看着不同的做事方式。正在建設Rest API和Java庫，並開始想知道這不能爲我做？但我同意REST將會是訪問該API的任何客戶端最可用的。但是，所有這些每個圖書館的工作似乎都是麻煩。如果我在API的輸出中向對象添加另一個參數，那麼我必須更新所有客戶端庫的值，並且錯誤必然會發生。有什麼建議？ – 2012-04-12 09:17:50

Trhift，n'est pas也是如此？你必須修改模式，每個人都必須重新編譯這個類到新的類......儘管Java，REST，我使用POJOs，可以共享。數據綁定包（JSON的JSON，XML的JAXB）可以很好地處理序列化/反序列化。然後是基本的HTTP客戶端（Apache或async-http-client）;或者更好，澤西客戶端，可以使訪問簡單。 – StaxMan 2012-04-12 18:41:31

有道理謝謝。結束寫一個正常的休息API和製作自定義庫。 – 2012-04-13 13:49:09

如果您的API足夠簡單，您可以使用REST和可接受的性能來表達它，否則可能會更好地堅持REST，因爲爲基於REST的API編寫客戶端代碼的屏障通常較低。

另一方面，如果REST存在複雜性或性能問題，請使用節儉或其他更合適的方法。

來源

2012-04-06 07:11:41

如果你自己開發不同的庫，你將會在同一條船上。我認爲即使沒有圖書館，人們也可以更容易地使用REST（或者如果他們實施他們自己的）。另一方面，如果您對Thrift的喜歡是二進制的，json也可以以類似的方式使用，請點擊此處查看更多信息http://bsonspec.org/

來源

2014-05-26 12:39:27 PSIXO

REST的一大優勢是您不必創建客戶端庫。您可以將開發人員指向您的端點列表，他們應該能夠從那裏找出它。一些設計很糟糕的REST服務將提供客戶端庫來掩蓋其醜陋，但如果API簡單且設計良好，則不需要。

來源

2014-11-04 19:16:22 miguel

Thrift作爲REST的公共API替代品嗎？

回答

相關問題