2011-05-25 109 views
3

我們想要實現一個API,我們有一個位於中央服務器上的數據庫,以及許多計算機的網絡。 在這些計算機上,將來會使用不同的編程語言開發若干本地程序,其中一些用於java,一些用於perl,C++等等。應該用什麼語言編寫API?

這些本地程序應該能夠訪問API函數和與數據庫交互。 那麼應該用什麼語言編寫API呢?以便它對其他語言具有約束力。是否有任何特定的架構應該實施? 有沒有提供有用信息的鏈接?

+2

我會說XML – 2011-05-25 20:57:44

+1

我使用樂高積木創建我的API ...不,但真的,我通常會使用REST API,可能使用JSON,這得到了很好的支持(http://www.json.org/) )。即使你使用的語言不支持它,語法也很容易解析imho。 – 2011-05-25 21:01:37

回答

3

如果API是純數據庫訪問,那麼REST Web服務是一個合理的選擇。它允許幾乎任何語言的(合理的)簡單的界面,並允許您選擇任何您認爲最適合編寫實際Web服務的語言。但是,以這種方式執行此操作時,您需要爲每個API調用支付額外的網絡調用費用。如果將Web服務與數據庫放在同一臺主機(或本地網絡)上,則可以將從Web服務到數據庫的網絡調用的成本降到最低,從而減少額外調用API的成本。

如果原料藥有業務邏輯在裏面,有兩家通過方法...

你可以寫的API爲可從多語言使用的庫。 C是一個很好的選擇,因爲大多數語言都可以鏈接C庫,但是您期望使用它的語言也會產生很大的影響。例如,如果您知道它始終將被託管在JVM上的語言使用,那麼任何JVM語言都可能是一個相當不錯的選擇。

另一種選擇是使用兩者的混合。用於數據庫訪問的REST API,以及用多種語言編寫的業務層庫。這個想法是你在應用程序端有商業邏輯,但它很簡單,你可以用多種語言編寫一個「客戶端庫」,知道如何調用REST API,然後將業務邏輯應用到它返回的結果。假設業務邏輯不太複雜(即僅限於合併/查看數據庫數據的方式),那麼這不是一個糟糕的解決方案。

好處是它應該比較容易提供一個可以被多種語言使用的「默認」庫,以及其他可用於實現它們的語言特定版本的庫。對於確定需要對數據庫進行哪些調用以及如何合併結果的情況可能很複雜,我認爲這是一個相當好的解決方案。

+0

感謝您的詳細解答!所以我可以從中得出結論:我應該使用REST,因爲API只能訪問網絡上各臺計算機的數據庫(存儲/讀取數據)。 – SLA 2011-05-26 17:40:03

1

我會訴諸web服務。只要你有一個與web服務交互的框架,你就可以使用哪種語言。根據您的需要,您可以公開一個簡單的REST API,或者全程使用SOAP/WSDL等。

+0

也許一些OData,如果你是這樣的事情。 – recursive 2011-05-25 21:02:28