webservice介面和http介面（API介面）的區別

    web service（SOAP）與HTTP介面的區別：



什么是web service？

答：soap請求是HTTP POST的一個專用版本，遵循一種特殊的xml訊息格式Content-type設定為: text/xml任何資料都可以xml化。



為什么要學習web service？

答：大多數對外介面會實現web service方法而不是http方法，如果你不會，那就沒有辦法對接。



web service相對http (post/get)有好處嗎？



1.介面中實現的方法和要求引數一目瞭然



2.不用擔心大小寫問題



3.不用擔心中文urlencode問題



4.程式碼中不用多次宣告認證(賬號,密碼)引數



5.傳遞引數可以為陣列，物件等...



web service相對http（post/get）快嗎？



答：由於要進行xml解析，速度可能會有所降低。



web service 可以被http（post/get）替代嗎？



答：完全可以，而且現在的開放平臺都是用的HTTP（post/get）實現的。

httpservice通過post和get得到你想要的東西

webservice就是使用soap協議得到你想要的東西，相比httpservice能處理些更加複雜的資料型別

http協議傳輸的都是字元串了，webservice則是包裝成了更複雜的物件。

1. webservice走HTTP協議和80埠。

2. 而你說的api，用的協議和埠，是根據開發人員定義的。

3. 這么說吧，api類似於cs架構，需要同時開發客戶端API和伺服器端程式。

4. 而WebService則類似於bs架構，只需要開發伺服器端，不需要開發客戶端，客戶端只要遵循soap協議，就可以呼叫。

java用webservice作介面有什么好處？直接提供一個請求地址就行了啊

答：對開發語言通用型別做xml對映處理，跨語言，跨平臺。

1.1、Web Service基本概念



Web Service也叫XML Web Service WebService是一種可以接收從Internet或者Intranet上的其它系統中傳遞過來的請求，輕量級的獨立的通訊技術。是:通過SOAP在Web上提供的軟體服務，使用WSDL檔案進行說明，並通過UDDI進行註冊。

XML：(Extensible Markup Language)擴充套件型可標記語言。面向短期的臨時資料處理、面向全球資訊網路，是Soap的基礎。

Soap：(Simple Object Access Protocol)簡單物件存取協議。是XML Web Service 的通訊協議。當使用者通過UDDI找到你的WSDL描述文件後，他通過可以SOAP呼叫你建立的Web服務中的一個或多個操作。SOAP是XML文件形式的呼叫方法的規範，它可以支援不同的底層介面，像HTTP(S)或者SMTP。

WSDL：(Web Services Description Language) WSDL 檔案是一個 XML 文件，用於說明一組 SOAP 訊息以及如何交換這些訊息。大多數情況下由軟體自動生成和使用。

UDDI (Universal Description, Discovery, and Integration) 是一個主要針對Web服務供應商和使用者的新專案。在使用者能夠呼叫Web服務之前，必須確定這個服務內包含哪些商務方法，找到被呼叫的介面定義，還要在服務端來編製軟體，UDDI是一種根據描述文件來引導系統查詢相應服務的機制。UDDI利用SOAP訊息機制（標準的XML/HTTP）來發布，編輯，瀏覽以及查詢註冊資訊。它採用XML格式來封裝各種不同型別的資料，並且傳送到註冊中心或者由註冊中心來返回需要的資料。

1.2、XML Web Service的特點

Web Service的主要目標是跨平臺的可互操作性。為了實現這一目標，Web Service 完全基於XML（可擴充套件標記語言）、XSD（XML Schema）等獨立於平臺、獨立於軟體供應商的標準，是建立可互操作的、分散式應用程式的新平臺。因此使用Web Service有許多優點:

1、跨防火牆的通訊

如果應用程式有成千上萬的使用者，而且分佈在世界各地，那么客戶端和伺服器之間的通訊將是一個棘手的問題。因為客戶端和伺服器之間通常會有防火牆或者代理伺服器。傳統的做法是，選擇用瀏覽器作為客戶端，寫下一大堆ASP頁面，把應用程式的中間層暴露給終端使用者。這樣做的結果是開發難度大，程式很難維護。 要是客戶端程式碼不再如此依賴於HTML表單，客戶端的程式設計就簡單多了。如果中間層元件換成Web Service的話，就可以從使用者介面直接呼叫中間層元件，從而省掉建立ASP頁面的那一步。要呼叫Web Service，可以直接使用Microsoft SOAP Toolkit或.net這樣的SOAP客戶端，也可以使用自己開發的SOAP客戶端，然後把它和應用程式連線起來。不僅縮短了開發週期，還減少了程式碼複雜度，並能夠增強應用程式的可維護性。同時，應用程式也不再需要在每次呼叫中間層元件時，都跳轉到相應的"結果頁"。

2、應用程式整合

企業級的應用程式開發者都知道，企業裡經常都要把用不同語言寫成的、在不同平臺上執行的各種程式整合起來，而這種整合將花費很大的開發力量。應用程式經常需要從執行的一臺主機上的程式中獲取資料；或者把資料傳送到主機或其它平臺應用程式中去。即使在同一個平臺上，不同軟體廠商生產的各種軟體也常常需要整合起來。通過Web Service，應用程式可以用標準的方法把功能和資料"暴露"出來，供其它應用程式使用。

XML Web services 提供了在松耦合環境中使用標準協議（HTTP、XML、SOAP 和 WSDL）交換訊息的能力。訊息可以是結構化的、帶型別的，也可以是鬆散定義的。

3、B2B的整合

B2B 指的是Business to Business，as in businesses doing business with other businesses,商家(泛指企業)對商家的電子商務，即企業與企業之間通過網際網路進行產品、服務及資訊的交換。通俗的說法是指進行電子商務交易的供需雙方都是商家(或企業、公司)，她們使用了Internet的技術或各種商務網路平臺，完成商務交易的過程。

Web Service是B2B整合成功的關鍵。通過Web Service，公司可以只需把關鍵的商務應用"暴露"給指定的供應商和客戶，就可以了，Web Service執行在Internet上，在世界任何地方都可輕易實現，其執行成本就相對較低。Web Service只是B2B整合的一個關鍵部分，還需要許多其它的部分才能實現整合。 用Web Service來實現B2B整合的最大好處在於可以輕易實現互操作性。只要把商務邏輯"暴露"出來，成為Web Service，就可以讓任何指定的合作夥伴呼叫這些商務邏輯，而不管他們的系統在什么平臺上執行，使用什么開發語言。這樣就大大減少了花在B2B整合上的時間和成本。

4、軟體和資料重用

Web Service在允許重用程式碼的同時，可以重用程式碼背後的資料。使用Web Service，再也不必像以前那樣，要先從第三方購買、安裝軟體元件，再從應用程式中呼叫這些元件；只需要直接呼叫遠端的Web Service就可以了。另一種軟體重用的情況是，把好幾個應用程式的功能整合起來，通過Web Service "暴露"出來，就可以非常容易地把所有這些功能都整合到你的門戶站點中，為使用者提供一個統一的、友好的介面。 可以在應用程式中使用第三方的Web Service 提供的功能，也可以把自己的應用程式功能通過Web Service 提供給別人。兩種情況下，都可以重用程式碼和程式碼背後的資料。

從以上論述可以看出，Web Service 在通過Web進行互操作或遠端呼叫的時候是最有用的。不過，也有一些情況，Web Service根本不能帶來任何好處，Web Service有一下缺點：

1、 單機應用程式

目前，企業和個人還使用著很多桌面應用程式。其中一些只需要與本機上的其它程式通訊。在這種情況下，最好就不要用Web Service，只要用本地的API就可以了。COM非常適合於在這種情況下工作，因為它既小又快。執行在同一臺伺服器上的伺服器軟體也是這樣。當然Web Service 也能用在這些場合，但那樣不僅消耗太大，而且不會帶來任何好處。

2、 區域網的一些應用程式

在許多應用中，所有的程式都是在Windows平臺下使用COM，都執行在同一個區域網上。在這些程式裡，使用DCOM會比SOAP/HTTP有效得多。與此相類似，如果一個.net程式要連線到區域網上的另一個.net程式，應該使用.net Remoting。其實在.net Remoting中，也可以指定使用SOAP/HTTP來進行Web Service 呼叫。不過最好還是直接通過TCP進行RPC呼叫，那樣會有效得多。

1.3、XML Web Service的應用

1.最初的 XML Web Service 通常是可以方便地併入應用程式的資訊來源，如股票價格、天氣預報、體育成績等等。

2.以 XML Web Service 方式提供現有應用程式，可以構建新的、更強大的應用程式，並利用 XML Web Service 作為構造塊。

例如，使用者可以開發一個採購應用程式，以自動獲取來自不同供應商的價格資訊，從而使使用者可以選擇供應商，提交訂單，然後跟蹤貨物的運輸，直至收到貨物。而供應商的應用程式除了在Web上提供服務外，還可以使用XML Web Service檢查客戶的信用、收取貨款，並與貨運公司辦理貨運手續。

WebService的框架JWS、Axis和CXF 比較



1、JWS是Java語言對WebService服務的一種實現，用來開發和發布服務。而從服務本身的角度來看JWS服務是沒有語言界限的。但是Java語言為Java開發者提供便捷發布和呼叫WebService服務的一種途徑。

2、Axis2是Apache下的一個重量級WebService框架，準確說它是一個Web Services / SOAP / WSDL 的引擎，是WebService框架的集大成者，它能不但能製作和發布WebService，而且可以生成Java和其他語言版WebService客戶端和服務端程式碼。這是它的優勢所在。但是，這也不可避免的導致了Axis2的複雜性，使用過的開發者都知道，它所依賴的包數量和大小都是很驚人的，打包部署發布都比較麻煩，不能很好的與現有應用整合為一體。但是如果你要開發Java之外別的語言客戶端，Axis2提供的豐富工具將是你不二的選擇。

3、XFire是一個高效能的WebService框架，在Java6之前，它的知名度甚至超過了Apache的Axis2，XFire的優點是開發方便，與現有的Web整合很好，可以融為一體，並且開發也很方便。但是對Java之外的語言，沒有提供相關的程式碼工具。XFire後來被Apache收購了，原因是它太優秀了，收購後，隨著Java6 JWS的興起，開源的WebService引擎已經不再被看好，漸漸的都敗落了。

4、CXF是Apache旗下一個重磅的SOA簡易框架，它實現了ESB（企業服務匯流排）。CXF來自於XFire專案，經過改造後形成的，就像目前的Struts2來自WebWork一樣。可以看出XFire的命運會和WebWork的命運一樣，最終會淡出人們的視線。CXF不但是一個優秀的Web Services / SOAP / WSDL 引擎，也是一個不錯的ESB匯流排，為SOA的實施提供了一種選擇方案，當然他不是最好的，它僅僅實現了SOA架構的一部分。

基於以上的認識，我們可以得知，雖然有了Java6，但是我們還可以選擇Axis2、XFire、CXF等。我們不能指望有了Java6 JWS，就能異想天開去實施SOA。如果要與別的語言互動，也許我們還有賴於Axis2等等，當然這不是唯一選擇，僅僅是一種可供選擇的方案。

還有，目前很多企業的應用還是基於Java5的，而Java5的專案不會瞬間都升級到Java6，如果要在老專案上做擴充套件，我們還有賴於其他開源的WS引擎。

對於現在的應用程式的遷移，如果你的應用程式是穩定而成熟的，並且在可預知的未來的情況下，只要很少的一些需求變更要做的話，那么儲存你的體力，不要去做「勞民傷財「的遷移工作了。

如果你的現有應用程式BUG纏身，效能，功能等等都一片糟糕的話，那就要考慮遷移了，那選哪個框架呢？先比較一下它們的不同之處：

1、Apache CXF 支援 WS-Addressing、WS-Policy、WS-RM、WS-Security和WS-I BasicProfile

2、Axis2 支援 WS-Addressing、WS-RM、WS-Security和WS-I BasicProfile，WS-Policy將在新版本里得到支援

3、Apache CXF 是根據Spring哲學來進行編寫的，即可以無縫地與Spring進行整合

4、Axis2 不是

5、Axis2 支援更多的 data bindings，包括 XMLBeans、JiBX、JaxMe 和 JaxBRI，以及它原生的 data binding（ADB）。

6、Apache CXF 目前僅支援 JAXB 和 Aegis，並且預設是 JAXB 2.0，與 XFire 預設是支援 Aegis 不同，XMLBeans、JiBX 和 Castor 將在 CXF 2.1 版本中得到支援，目前版本是 2.0.2

7、Axis2 支援多種語言，它有 C/C 版本。

8、Apache CXF 提供方便的Spring整合方法，可以通過註解、Spring標籤式配置來暴露Web Services和消費Web Services

如何抉擇：

1、如果應用程式需要多語言的支援，Axis2 應當是首選了；

2、如果應用程式是遵循 Spring 哲學路線的話，Apache CXF 是一種更好的選擇，特別對嵌入式的 Web Services 來說；

3、如果應用程式沒有新的特性需要的話，就仍是用原來專案所用的框架，比如 Axis1，XFire，Celtrix 或 BEA 等等廠家自己的 Web Services 實現，就別勞民傷財了。