語言不可知的API

Question

我打算建立一個網絡服務或其他一些通過互聯網公開的服務。我想爲應用程序創建一個API來與此服務交互。我希望API能夠用於不同的語言，如Java，C++，C＃或PHP。我如何爲我的API維護一個代碼庫，但是爲所有這些語言分發好的打包二進制文件？另外，我可能想考慮這也可能是跨平臺的。

更新1

我對Web服務的初期，但我 認爲，關鍵點之一是 大量的模具支持基於的 描述 實施客戶像WDSL這樣的服務。 我沒有交付任何客戶端 軟件與我所做的任何事情，我 期望任何用戶能夠建立自己的客戶 適合其 需要。 --Brabster的答案

我不反對使它成爲一個直接的Web服務，然後發出一個WSDL文件。但是，如果我想讓客戶端API執行一些邏輯，加密，錯誤檢查等操作呢？

更新2

至於期待客戶使用自己的API做任何事，你 不能是 ！沒有什麼東西可以做 ，以確保API的消費者 能夠做任何事。 這就是爲什麼健壯的錯誤處理很重要的原因。你必須檢查並加倍 檢查任何和所有來自客戶端的 。您一定對 懷疑它，甚至認爲 它是惡意的。這個事實確實沒有什麼好辦法。 --Ryan Guill的答案

我最初的想法是在.NET中創建一個DLL或程序集，然後客戶端正在調用此代碼運行客戶端。這段代碼可以通過任何通信協議回到服務器，但是我的API將會在他們的盒子上運行。我猜REST並沒有真正做到這一點。看起來在REST中，一切仍然是一個HTTP帖子。這是幾乎沒有肥皂的Web服務。

更新3

我已經接受了瑞安紀廉的答案。我認爲總的想法是我需要公開某種網絡服務，而對客戶端來說是最低的障礙。這樣任何人都可以連接。然後讓我的所有代碼在服務器上運行。這似乎被認爲是唯一真正想實現我所追求的平臺和語言獨立性的人。

感謝您的所有輸入。

Answer 1

我會用一個REST API，類似Flickr的API的工作方式：http://flickr.com/services/api/

這是相當簡單的創建和維護，最大的缺點是，它需要大量的文檔資料（但幾乎任何方式你做的API會有這個問題），而且強大的錯誤處理是必須的。

但在我看來，這是創建最接近跨平臺/跨語言的API的最佳方式。

點擊此處瞭解詳情：http://www.xfront.com/REST-Web-Services.html

更新：提交者添加了以下的帖子：

我不反對使它然後直Web服務給予了WSDL文件。但是，如果我想讓客戶端API執行一些邏輯，加密，錯誤檢查等操作呢？

我個人不喜歡使用SOAP（使用WSDL）。在服務器和客戶端都使用SOAP有很多固有的開銷。我認爲這就是爲什麼你看到使用REST編寫越來越多的公共API。它真正降低了進入最低公共分母的障礙，允許任何可以使用基本HTTP（GET和POST（也是PUT和DELETE用於「正確」的方式））使用API​​。

公共API的使用REST寫的一些例子：twitter，vimeo，Google

至於預期正在使用您的API做任何事情，你不能在客戶端！沒有什麼能夠做到的，以確保API的使用者能夠做正確的事情。這就是強大的錯誤處理如此重要的原因。您必須檢查並仔細檢查來自客戶的任何和所有內容。你必須永遠懷疑它，甚至認爲它是惡意的。這個事實真的沒有好的方法。

更新2：提交者添加了以下的帖子：

我最初的想法是建立在.NET DLL或組裝，然後在客戶端發出的呼叫到這個代碼運行客戶端。這段代碼可以通過任何通信協議回到服務器，但是我的API將會在他們的盒子上運行。我猜REST並沒有真正做到這一點。看起來在REST中，一切仍然是一個HTTP帖子。這是幾乎沒有肥皂的Web服務。

您當然可以做到這一點，但這隻適用於.NET語言，這意味着您的跨平臺和跨語言的好處不在窗口。最後，你真的阻止了什麼嗎？開發人員將使用您的遠程API或您的本地DLL或程序集。無論哪種方式，他將不得不知道如何使用它並正確使用它，否則你會拋出一個錯誤。你所做的只是改變錯誤發生的位置。這可能對你很重要（如果是這樣，請說明原因），但實際上並沒有改變方程式中的任何內容。

但你是在說REST有些正確的是一種像無SOAP的Web服務。從技術上來說，REST也是Web服務，它只是Web服務通常意味着SOAP。這是實現同樣目標的另一種方式。最大的區別在於它需要更多的編程和思考（並且可能在客戶端有更多的編程），但是爲了穩健性，消費者和服務器都需要更少的開銷，以及API的最廣泛的受衆羣體。它確實是最低的共同標準。

Answer 2

我在Web服務的早期階段，但我認爲其中一個關鍵點是很多工具都支持基於服務描述（如WDSL）來實現客戶端。

我還沒有交付過任何客戶端軟件，我希望任何用戶都能夠構建適合他們需求的客戶端。

如果您按照您的其他答案中的建議查看flickr API，我不認爲它們提供客戶端代碼，其他人已經構建並貢獻了客戶端的東西。

Answer 3

簡單的答案，沒有。

複雜的答案：創建一個API並將其編譯爲COM DLL。然後，爲不能處理的語言構建包裝代碼。

簡單的答案＃2，使原始服務如此普通或普遍接受，以至於不需要API（我通常通過服務器端數據庫輪詢來實現這一點）醜陋但任何可以訪問數據庫的語言都可以利用該程序）。

Answer 4

我建議寫在HAXE編程語言的API，使源代碼可以直接轉換到你所提到的所有編程語言。 Haxe編程語言可以被翻譯（或「trans-compile」）到您在原始文章中提到的所有編程語言以及其他一些編程語言。