Web服務框架與定製的XML over HTTP協議？

Question

我找具體準則何時使用Web服務框架與該進行通信使用HTTP上的XML一個證據充分的自定義協議。

對於客戶端和服務器端代碼，我不關心性能，而是關注可維護性和易用性。例如，我可以開發一個自定義協議，它可以在不寫大量Web服務框架似乎需要的描述符文件的情況下對話XML。

請列出具體功能 Web服務帶來的表格。

Answer 1

WS的好處通常來源於工具支持來生成客戶端，服務器存根和描述符以及管道優勢，如安全性，加密和其他可擴展性。如果沒有工具，那麼處理WS請求的負擔就會很高，並且對於結果的價值相對較低。

IMO如果你沒有工具 - 這兩種方法似乎是相當高的維護。選擇最短的路徑。如果您確實有工具支持，請轉到WS路線並讓工具完成繁重工作。

Answer 2

RESTful Web服務是非常低的儀式。如果像Atom Publishing Protocol這樣的東西適合你，那就是我會採用的路線。

Answer 3

爲什麼你考慮重新發明輪子，如果你沒有表現 - 問題或其他疑問，WS不會做這項工作？

對於客戶端來說，這將會（在大多數情況下）成爲最簡單的方式來使用您的服務。

描述符文件無論如何都應該（在.NET世界上至少）從服務器處理。

Answer 4

這是經典的構建與購買的問題。即使框架是免費的，也有投資學習和配置。獲得的框架具有規模經濟，因爲它會從維護它的實體中獲得增強，但是你並沒有推動這一過程。它可能會添加您想要的功能，或者會破壞您的代碼的功能，您無法預先知道。建立自己意味着啓動時間和後期維護。根據您的員工隊伍，專家可能會繼續前進，隨着代碼變得陳舊，維護它的知識也會隨之而來。這個問題有許多優點和缺點，在選擇你的方向之前你應該考慮所有這些。

Answer 5

我會說這是一個好主意，設計的業務邏輯能夠在以後插入不同的訪問方法或框架。讓不同的最終用戶想要/需要不同的訪問方法（比如SOAP，REST或其他一些尚未發明的技術）並不是聞所未聞。

Answer 6

我們大量使用的內部Web服務我們的生產系統之間，而且都是XML香草HTTP上，看不到SOAP。我們發現WS堆棧的繁瑣特性，即使是像XFire這樣的更好的堆棧，也不值得。

Answer 7

我一直在客戶端這僅僅是XML通過HTTP發送的Web服務之前。我發現它非常簡單易用。我用JiBX來創建一個Java對象我的XML請求，並解壓到使用JiBX過一個Java對象的XML響應。