使用API Mgmt將SOAP/JMS打包爲RESTful API。工具實用？使用API Mgmt將SOAP/JMS打包爲REST。工具實用？
API管理工具（如apigee和wso2-am）聲稱支持將SOAP服務作爲REST-JSON公開，但實際上我發現很難映射這兩者並且沒有看到我們可以通過公開所有SOAP/JMS資源通過Restful API管理。工具。 SOAP服務在結構上與REST有很大的不同，在REST中可以有多個操作集，通常可能有很多請求和響應元素映射到業務案例。
另一方面，REST基於四個HTTP動詞GET，POST，PUT和DELETE，它們將被巧妙地處理以處理定義的資源。 我們可以使用什麼樣的設計原則來進行映射？
例如，實現上述轉換可能需要爲GET請求添加大量xml內容到您的HTTP標頭，並稍後處理它，這不是HTTP和REST的標準實現。
感謝， Wajid
正如Ian所言，SOAP服務通常不會直接映射到RESTful API。我不知道任何供應商提供的SOAP-to-REST轉換工具，它們將自動從一組SOAP服務中創建一個漂亮的RESTful API。
假設你打算將RESTful API暴露給許多開發人員，並且/或者關心它的可用性（美觀，我認爲），我的建議是通過分析你嘗試的資源來設計RESTful API封裝在RESTful API中，而不必擔心您擁有的SOAP服務。假設您可以將域映射到資源，您可以想出一個可用，直觀的RESTful界面。
然後，當您對RESTful API感到滿意時，使用SOAP服務作爲構建塊。正如Ian解釋的，API管理層應該幫助您將RESTful輸入轉換爲SOAP請求，混合多個調用，將響應中的信息提取到您選擇的響應負載中，並幫助您保護和擴展您的API。如果因爲無法將SOAP構建塊組合到所需的RESTful界面中而發現需要對RESTful API設計作出妥協，至少您會了解到您所處的位置。
這是一個很好的問題。 REST是一個非常濫用的詞。許多（大多數情況下）SOAP服務本質上是事務性的，因此不適合RESTful範式。儘管如此，關於使用REST進行非RESTful服務的宗教辯論有點愚蠢，恕我直言。
您當然可以爲此使用API管理產品（我爲API管理公司工作）。但事實上，它並不像供應商聲稱的那麼簡單。有些產品可以在SOAP和REST之間進行聲明式調解，但是所得到的RESTful服務可能會很糟糕，您可能需要至少從響應邊緣和請求文檔中刪除/添加SOAP文檔。當你開始轉換XML < - > JSON時，你會遇到各種有趣的問題，像Array來排序映射。
也就是說，一個好的API管理產品（特別是一個好的API網關）將提供強大的聲明性功能讓您關閉，並結合更先進的映射和中介功能，讓您一路走到您想要的地方。如果您選擇了正確的產品，那麼您可能還會從多個後端服務中獲得一些很好的編排功能來構建複合API。
如果你想了解更多信息，請隨時給我發消息。我認爲我不適合在這個論壇上爲我的公司提供商業廣告。
Ian
我不認爲這是可能的自動，至少不是沒有AI。
首先，您必須將每個操作名稱拆分爲兩部分：具有IRI和VERB的資源。
例如：
GetLastTradePrice將至少GET /lastTradePrice或與另外的變換GET tradePrices/lastHello將GET /greeting?name="{name}"CreateUser，GetUserName，DeleteUserById將POST /users，GET /users/{id}?fields="name"，DELETE /users/{id}如果你想有很好的IRI來調試你的路由器，並鏈接建設者服務器端，那麼你需要一個嚴格的概念或AI來做到這一點。如果不是那麼你的運氣，IRI結構並不重要，所以你可以使用/resources/{id}爲每個資源。例如/users可以是/resources/static:1和/users/123可以是/resources/123。如果每個資源在您的系統中都有一個唯一的ID。如果不是，那麼你必須使用獨特的子類別，例如/resources/avz5ag6u:123。如果沒有AI，或在您的SOAP服務的一些嚴格的命名概念，你將無法通過POST重用的IRI像/users，GET，或/users/{id}通過PUT，GET，DELETE，但由於通過REST每個資源都可以不是一個悲劇有多個IRIs。請注意它們是獨特的...
問題是與這些鏈接的含義部分（VERB + IRI）。通過REST，您可以導航檢查與鏈接相關的元數據，例如IANA link relations與vendor specific MIME types，由HAL或rdf:Property s描述的自定義RDF vocab由Hydra（如果我們正在討論REST JSON ofc）。我認爲可以從XSD中生成參數和返回值驗證/描述部分，但是您的鏈接元數據將很困難。爲此你需要一個AI。如果你很幸運，你的SOAP服務已經提供了一些RDF信息，通過這樣的服務，我認爲自動映射是可能的，否則我不這麼認爲，反正這將是一項艱鉅的工作。您將無法調試或改進生成的服務，因爲路由將使用匿名IRI或IRI模板。
因此在大多數情況下，不可能完全自動完成此操作。您需要一些嚴格的操作命名概念和/或現有的RDF描述到您的SOAP服務。即使如此，我認爲編寫REST服務生成器也是一項艱鉅的任務。沒有這些，你必須做一些或更多的手動工作，比如用REST特定的東西來註釋你的SOAP服務，或者在你的WSDL文件中寫入一些REST特有的屬性，並使用它們來生成REST服務。現在這是這份工作的一部分。
另一部分是重用SOAP服務的業務邏輯。如果您的中心佈局像乾淨，洋蔥或六角形/端口&適配器，那麼應該很容易爲REST交付或端口添加新的適配器。如果你不使用這樣的體系結構，那麼你必須手動編寫整個REST服務或神級REST適配器。
在我看來寫一個SOAP - > REST生成器不值得。手動編寫REST服務更容易。