Tìm hiểu về Web Service – GP Coder (Lập trình Java)

Trong bài này, tất cả chúng ta sẽ cùng tìm hiểu và khám phá về Web service là gì, những thành phần của một web service, những loại web service, so sánh SOAP với REST web service .Bài này khá nặng về triết lý, mình xin phép tổng hợp lại từ những tài liệu mình tìm hiểu thêm được từ những trang khác cũng như kinh nghiệm tay nghề thực tiễn của mình để giúp những bạn có cái nhìn không thiếu nhất về web service .

Web service – Thương Mại Dịch Vụ web là gì ?

Web service ( dịch vụ web ) là tập hợp những giao thức và tiêu chuẩn mở được sử dụng để trao đổi tài liệu giữa những ứng dụng hoặc giữa những mạng lưới hệ thống .

Các ứng dụng phần mềm được viết bằng các ngôn ngữ lập trình khác nhau hoặc chạy trên các nền tảng khác nhau, chúng có thể sử dụng các web service để trao đổi dữ liệu qua lại theo cách tương tự như liên lạc giữa các quá trình trên một máy tính.

Các thành phần của web service

Nền tảng cơ bản của web service ( WS ) là XML + HTTP. Nó gồm có những thành phần chính sau :

  • UDDI – Universal Description, Discovery, and Integration (Mô tả, Khám phá và Tích hợp Toàn cầu): UDDI là một tiêu chuẩn dựa trên XML để mô tả, xuất bản và tìm kiếm các dịch vụ web.
  • WSDL – Web Service Description Language (Ngôn ngữ mô tả web service): WSDL là một ngôn ngữ dựa trên XML để mô tả các dịch vụ web và cách truy cập chúng. WSDL mô tả một dịch vụ web, cùng với định dạng thông báo và các chi tiết giao thức cho dịch vụ web.
  • SOAP – Simple Object Access Protocol (Giao thức truy cập đối tượng đơn giản): SOAP là một giao thức dựa trên XML đơn giản cho phép các ứng dụng trao đổi thông tin qua HTTP.

XML – eXtensible Markup Language

Là một chuẩn mở do W3C đưa ra cho cách thức mô tả dữ liệu, nó được sử dụng để định nghĩa các thành phần dữ liệu trên trang web và cho những tài liệu B2B. Về hình thức, XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML nhưng HTML định nghĩa thành phần được hiển thị như thế nào thì XML lại định nghĩa những thành phần đó chứa cái gì. Với XML, các thẻ có thể được lập trình viên tự tạo ra trên mỗi trang web và được chọn là định dạng thông điệp chuẩn bởi tính phổ biến và hiệu quả mã nguồn mở.

Do dịch vụ Web là sự tích hợp của nhiều thành phần khác nhau nên nó sử dụng những tính năng và đặc trưng của những thành phần đó để tiếp xúc. XML là công cụ chính để xử lý yếu tố này và là kiến trúc nền tảng cho việc thiết kế xây dựng một dịch vụ Web, toàn bộ tài liệu sẽ được chuyển sang định dạng thẻ XML. Khi đó, những thông tin mã hóa sẽ trọn vẹn tương thích với những thông tin theo chuẩn của SOAP hoặc XML-RPC và hoàn toàn có thể tương tác với nhau trong một thể thống nhất .

WSDL – Web Service Description Language

WSDL định nghĩa cách diễn đạt dịch vụ Web theo cú pháp tổng quát của XML, gồm có những thông tin :

  • Tên dịch vụ.
  • Giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của dịch vụ Web.
  • Loại thông tin: thao tác, tham số, những kiểu dữ liệu (có thể là giao diện của dịch vụ Web cộng với tên cho giao diện này).

Một WSDL hợp lệ gồm hai phần : phần giao diện diễn đạt giao diện và phương pháp liên kết và phần thi hành miêu tả thông tin truy xuất CSDL. Cả hai phần này sẽ được lưu trong 2 tập tin XML tương ứng là tập tin giao diện dịch vụ và tập tin thi hành dịch vụ. Giao diện của một dịch vụ Web được miêu tả trong phần này đưa ra phương pháp làm thế nào để tiếp xúc qua dịch vụ Web. Tên, giao thức link và định dạng thông điệp nhu yếu để tương tác với dịch vụ Web được đưa vào thư mục của WSDL .WSDL thường được sử dụng phối hợp với XML schema và SOAP để phân phối dịch vụ Web qua Internet. Một client khi liên kết tới dịch vụ Web hoàn toàn có thể đọc WSDL để xác lập những tính năng sẵn có trên server. Sau đó, client hoàn toàn có thể sử dụng SOAP để lấy ra công dụng đúng mực có trong WSDL .

Universal Description, Discovery, and Integration ( UDDI )

Để hoàn toàn có thể sử dụng những dịch vụ, thứ nhất client phải tìm dịch vụ, ghi nhận thông tin về cách sử dụng và biết được đối tượng người dùng nào cung ứng dịch vụ. UDDI định nghĩa một số ít thành phần cho biết những thông tin này, được cho phép những client săn lùng và nhận những thông tin được nhu yếu khi sử dụng dịch vụ Web .Cấu trúc UDDI :

  • Trang trắng – White pages: chứa thông tin liên hệ và các định dạng chính yếu của dịch vụ Web, chẳng hạn tên giao dịch, địa chỉ, thông tin nhận dạng… Những thông tin này cho phép các đối tượng khác xác định được dịch vụ.
  • Trang vàng – Yellow pages: chứa thông tin mô tả dịch vụ Web theo những loại khác nhau. Những thông tin này cho phép các đối tượng thấy được dịch vụ Web theo từng loại với nó.
  • Trang xanh – Green pages: chứa thông tin kỹ thuật mô tả các hành vi và các chức năng của dịch vụ Web.
  • Loại dịch vụ – tModel:  chứa các thông tin về loại dịch vụ được sử dụng.

Những thông tin về dịch vụ Web được sử dụng và công bố lên mạng sử dụng giao thức này. Nó sẽ kích hoạt những ứng dụng để tìm kiếm thông tin của dịch vụ Web khác nhằm mục đích xác lập xem dịch vụ nào sẽ cần đến nó .

SOAP – Simple Object Access Protocol

Chúng ta đã hiểu cơ bản dịch vụ Web như thế nào nhưng vẫn còn một yếu tố khá quan trọng. Đó là làm thế nào để truy xuất dịch vụ khi đã tìm thấy ? Câu vấn đáp là những dịch vụ Web hoàn toàn có thể truy xuất bằng một giao thức là Simple Object Access Protocol – SOAP. Nói cách khác tất cả chúng ta hoàn toàn có thể truy xuất đến UDDI registry bằng những lệnh gọi trọn vẹn theo định dạng của SOAP .SOAP là một giao thức tiếp xúc có cấu trúc như XML. Nó được xem là cấu trúc xương sống của những ứng dụng phân tán được kiến thiết xây dựng từ nhiều ngôn từ và những hệ điều hành quản lý khác nhau. SOAP là giao thức đổi khác những thông điệp dựa trên XML qua mạng máy tính, thường thì sử dụng giao thức HTTP .Một client sẽ gửi thông điệp nhu yếu tới server và ngay lập tức server sẽ gửi những thông điệp vấn đáp tới client. Cả SMTP và HTTP đều là những giao thức ở lớp ứng dụng của SOAP nhưng HTTP được sử dụng và gật đầu thoáng rộng hơn bởi thời nay nó hoàn toàn có thể thao tác rất tốt với hạ tầng Internet .

Cấu trúc một thông điệp theo dạng SOAP

Thông điệp theo định dạng SOAP là một văn bản XML thông thường gồm có những thành phần sau :

  • Phần tử gốc – envelop: phần tử bao trùm nội dung thông điệp, khai báo văn bản XML như là một thông điệp SOAP.
  • Phần tử đầu trang – header: chứa các thông tin tiêu đề cho trang, phần tử này không bắt buộc khai báo trong văn bản. Header còn có thể mang những dữ liệu chứng thực, những chứ ký số, thông tin mã hóa hay cài đặt cho các giao dịch khác.
  • Phần tử khai báo nội dung chính trong thông điệp – body, chứa các thông tin yêu cầu và thông tin được phản hồi.
  • Phần tử đưa ra các thông tin về lỗi – fault, cung cấp thông tin lỗi xảy ra trong qúa trình xử lý thông điệp.

Một SOAP đơn thuần trong body toàn thân sẽ lưu những thông tin về tên thông điệp, tham chiếu tới một bộc lộ của dịch vụ, một hoặc nhiều tham số. Có 3 kiểu thông tin sẽ được đưa ra khi truyền thông tin : request message ( tham số gọi thực thi một thông điệp ), respond message ( những tham số trả về, được sử dụng khi nhu yếu được phân phối ) và ở đầu cuối là fault message ( thông tin thực trạng lỗi ) .Ví dụ :




 

...

 

...
  
  ...
  

 


Kiểu truyền thông

Có 2 kiểu tiếp thị quảng cáo

  • Remote procedure call (RPC): cho phép gọi hàm hoặc thủ tục qua mạng. Kiểu này được khai thác bởi nhiều dịch vụ Web.
  • Document: được biết đến như kiểu hướng thông điệp, nó cung cấp giao tiếp ở mức trừu tượng thấp, khó hiểu và yêu cầu lập trình viên mất công sức hơn.

Hai kiểu tiếp thị quảng cáo này cung ứng những định dạng thông điệp, tham số, lời gọi đến những API khác nhau nên việc sử dụng chúng tùy thuộc vào thời hạn và sự tương thích với dịch vụ Web cần kiến thiết xây dựng .

Cấu trúc dữ liệu

Cung cấp những định dạng và khái niệm cơ bản giống như trong những ngôn từ lập trình khác như kiểu tài liệu ( int, string, date … ) hay những kiều phức tạp hơn như struct, array, vector … Định nghĩa cấu trúc tài liệu SOAP được đặt trong namespace SOAP-ENC .

Mã hóa

Giả sử service requester và service provider được tăng trưởng trong Java, khi đó mã hóa SOAP là làm thế nào quy đổi từ cấu trúc tài liệu Java sang SOAP XML và ngược lại, chính bới định dạng cho Web Service chính là XML. Bất kỳ một thiên nhiên và môi trường thực thi SOAP nào cũng phải có một bảng chứa thông tin ánh xạ nhằm mục đích quy đổi từ ngôn từ Java sang XML và từ XML sang Java – bảng đó được gọi là SOAPMappingRegistry. Nếu một kiểu tài liệu được sử dụng dưới một dạng mã hóa thì sẽ có một ánh xạ sống sót trong bộ ĐK của môi trường tự nhiên thực thi SOAP đó .

Web Services Architecture

  • Service Discovery : Phần kiến ​​trúc này chịu trách nhiệm tập trung các dịch vụ vào một nơi đăng ký chung và cung cấp chức năng publish/ search dễ dàng. Điều này được xử lý bởi UDDI.
  • Service Description : Một trong những tính năng thú vị nhất của Dịch vụ web là chúng tự mô tả. Điều này có nghĩa là, một khi Dịch vụ web được định vị, nó sẽ cho chúng ta biết những hoạt động mà nó hỗ trợ và cách gọi nó. Điều này được xử lý bởi WSDL.
  • Service Invocation : Gọi một dịch vụ web liên quan đến việc truyền tin nhắn giữa Client và Server. SOAP chỉ định cách chúng ta nên định dạng các thông báo yêu cầu (request) đến Server và cách Server định dạng các thông điệp phản hồi (response) của nó.
  • Service Transport : Cuối cùng, tất cả các thông báo này phải được truyền đi bằng cách nào đó giữa Client và Server. Giao thức được lựa chọn cho phần kiến ​​trúc này là HTTP – giao thức được sử dụng để truy cập các trang web thông thường trên Internet. Chúng ta cũng có thể sử dụng các giao thức khác, nhưng HTTP hiện là giao thức được sử dụng nhiều nhất.

Web service hoạt động giải trí như thế nào ?

Một ứng dụng WS gồm có 2 thành phần : Client và Server tiếp xúc với nhau qua giao thức HTTP .

  • Client gửi yêu cầu qua các lời gọi hàm thông qua HTTP Request đến Server
  • Server gửi các kết quả được thực thi các ở hàm thông qua HTTP Request

Mô hình hoạt động giải trí của ứng dụng WebService gồm 3 thành phần chính :

  • UDDI service registry: Công cụ giúp nhà phát triển WS công bố những thông tin về WebService của mình cho cộng đồng các nhà phát triển ứng dụng. Người dùng sẽ dựa vào các thông tin này để sử dụng WebService trong ứng dụng riêng của minh.
  • Web service: Chứa giao thức SOAP định dạng dữ liệu, tài liệu WSDL định nghĩa các hàm trong WebService, XML để xây dựng ứng dụng phân tán.
  • Applicantion Client: Ứng dụng phía Client sử dụng WebService xây dựng riêng cho mình
    Cách thức hoạt động có thể mô tả như sau: Đầu tiên, Applicantion Client cần truy vấn các mẫu tin.

UDDI theo 1 thông tin nào đó ( ví dụ điển hình tên loại ) để xác lập WebService cần tìm. Khi đã xác lập được WebService cần cho ứng dụng, Client có thế lấy thông tin về địa chỉ của tài liệu WSDL của WebService này dựa trên mẫu tin UDDI. Tài liệu WSDL sẽ miêu tả phương pháp liên lạc với WebService, định dạng gói tin truy vấn và phản hồi. Dựa vào những thông tin này, Client hoàn toàn có thể tạo những gói tin SOAP tương ứng để liên lạc với Service .

Các loại Web service

Có 2 loại web service chính :

  • SOAP web services.
  • RESTful web services.

SOAP Web Service là gì ?

SOAP là viết tắt của Simple Object Access Protocol.

SOAP (Simple Object Access Protocol) là giao thức sử dụng XML để định nghĩa dữ liệu dạng thuần văn bản (plain text) thông qua HTTP. SOAP là cách mà Web Service sử dụng để truyền tải dữ liệu. Vì dựa trên XML nên SOAP là một giao thức không phụ thuộc platform cũng như bất kì ngôn ngữ lập trình nào. Chúng ta có thể viết bằng Java, PHP, .NET, … và triển khai trên Window, Linux, …

RESTful web service là gì ?

REST là viết tắt của REpresentational State Transfer.

REST là một loại kiến trúc ứng dụng ( architectural style ), không phải là một protocol .RESTful Web Service là những Web Service được viết dựa trên kiến trúc REST. REST đã được sử dụng thoáng rộng để sửa chữa thay thế cho những Web Service dựa trên SOAP và WSDL .Tương tự SOAP, REST cũng không nhờ vào platform cũng như bất kỳ ngôn từ lập trình nào .

REST có thể sử dụng SOAP web service như một implement của nó.

REST định nghĩa những quy tắc kiến trúc để bạn phong cách thiết kế Web services, chú trọng vào tài nguyên mạng lưới hệ thống, gồm có những trạng thái tài nguyên được định dạng như thế nào và được truyền tải qua HTTP, và được viết bởi nhiều ngôn từ khác nhau. Nếu tính theo số dịch vụ mạng sử dụng, REST đã nổi lên trong vài năm qua như thể một quy mô phong cách thiết kế dịch vụ chiếm lợi thế. Trong trong thực tiễn, REST đã có những ảnh hưởng tác động lớn và gần như sửa chữa thay thế SOAP và WSDL vì nó đơn thuần và dễ sử dụng hơn rất nhiều .REST tuân thủ 4 nguyên tắc phong cách thiết kế cơ bản sau :

  • Sử dụng các phương thức HTTP một cách rõ ràng.
  • Phi trạng thái.
  • Hiển thị cấu trúc thư mục như các URls.
  • Truyền tải JavaScript Object Notation (JSON), XML hoặc cả hai.

Sử dụng những phương pháp HTTP một cách rõ ràng

REST đặt ra một quy tắc yên cầu lập trình viên xác lập rõ hành vi của service trải qua những phương pháp của HTTP .

Các hành động của một webservice thông thường bao gồm tạo dữ liệu (Create), lấy dữ liệu (Read),cập nhập dữ liệu (Update) hoặc xóa dữ liệu (Delete). Các hành động này còn được gọi là CRUD.

Thiết lập một ánh xạ 1-1 giữa các hành động (CRUD) và các phương thức HTTP:

  • POST : để tạo một tài nguyên trên Server.
  • GET : để truy xuất một tài nguyên.
  • PUT : để thay đổi trạng thái một tài nguyên hoặc để cập nhật nó.
  • DELETE : để huỷ bỏ hoặc xoá một tài nguyên.

Lưu ý : những nguyên tắc ở trên là không bắt buộc, trên thực tiễn tất cả chúng ta hoàn toàn có thể sử dụng phương pháp GET để nhu yếu lấy, tạo, sửa hoặc xóa dữ liệu trên Server. Tuy nhiên, REST đưa ra những nguyên tắc ở trên mục tiêu đưa mọi thứ trở lên rõ ràng và dễ hiểu .

Phi trạng thái ( Stateless )

Một đặc thù của REST là phi trạng thái ( stateless ), có nghĩa là nó không lưu giữ thông tin của client. Chẳng hạn bạn vừa gửi nhu yếu để xem trang thứ 2 của một tài liệu, và giờ đây bạn muốn xem trang tiếp theo ( sẽ là trang 3 ). REST không tàng trữ lại thông tin rằng trước đó nó đã Giao hàng bạn trang số 2. Điều đó có nghĩa là REST không quản trị phiên thao tác ( Session ) .Hình dưới đây minh họa một ứng dụng có tàng trữ trạng thái, nó biết người dùng đang xem trang số mấy. Và người dùng chỉ cần nhu yếu “ Trang Tiếp theo ” để nhận được trang mong ước .

Với những phong cách thiết kế phi trạng thái, Client phải gửi nhu yếu rõ ràng, gồm có số thự tự của trang cần xem .

Như vậy, những thành phần Server phi trạng thái ít phức tạp hơn để phong cách thiết kế, viết và phân chia trải qua Server được cân đối tải. Dịch Vụ Thương Mại phi trạng thái không chỉ hoạt động giải trí tốt hơn, nó còn chuyển hầu hết vai trò duy trì trạng thái sang ứng dụng ở Client. Trong một dịch vụ mạng RESTful, Server chịu nghĩa vụ và trách nhiệm đưa ra những phản hồi và cung ứng một phương pháp được cho phép Client duy trì trạng thái ứng dụng của chính nó .

Đưa ra cấu trúc thư mục giống những URI

REST đưa ra một cấu trúc để người dùng có thể truy cập vào tài nguyên của nó thông qua các URL, tài nguyên ở đây là tất cả những cái mà bạn có thể gọi tên được (Video, ảnh, báo cáo thời tiết,..)
Bạn cần tạo ra các REST serivce để nó trả về cho người dùng các nguồn tài nguyên tương ứng.

Các địa chỉ REST service cần phải thật trực quan đến mức người dùng dễ đoán. Hãy nghĩ về một địa chỉ ( URI ) giống như một gợi ý rõ ràng, dễ đoán rằng nó đang trỏ tới cái gì và cung ứng tài nguyên gì. Tóm lại, cấu trúc của một URI nên được đơn thuần, hoàn toàn có thể Dự kiến, và dễ hiểu .Hãy xem một URL dưới đây, nó cung ứng list bài viết của một ngày đơn cử, và nó dễ hiểu so với người dùng .


https://final-blade.com/posts/2019-05-20

Một vài nguyên tắc bổ trợ để quan tâm trong khi nói về cấu trúc địa chỉ của RESTful Web service là :

  • Giấu các đuôi tài liệu mở rộng của bản gốc trong máy chủ (.jsp, .php, .asp), nếu có, vì vậy bạn có thể giấu một số thứ mà không cần thay đổi địa chỉ Urls.
  • Để mọi thứ là chữ thường.
  • Thay thế các khoảng trống bằng gạch chân hoặc hoặc gạch nối (một trong hai loại).
  • Tránh các chuỗi yêu cầu càng nhiều càng tốt.
  • Thay vì sử dụng mã (404 Not Found) khi yêu cầu địa chỉ cho một phần đường dẫn, luôn luôn cung cấp một trang mặc định hoặc tài nguyên như một phản hồi.

Truyền tải XML, JSON hoặc cả hai

Khi Client gửi một nhu yếu tới web service nó thường được truyền tải dưới dạng XML hoặc JSON và thường thì nhận về với hình thức tựa như .Đôi khi Client cũng hoàn toàn có thể chỉ định kiểu tài liệu nhận về mà nó mong ước ( JSON, hoặc XML, .. ), những chỉ định này được gọi là những kiểu MINE, nó được gửi kèm trên phần HEADER của request .Dưới đây là những kiểu MIME thông dụng thường sử dụng với REST service :

Extention Content-Type
.json application/json
.xml application/xml

Tham khảo thêm những MIME type khác : https://www.freeformatter.com/mime-types-list.htmlVí dụ : Client gửi một nhu yếu để lấy thông tin list bài viết, và nhu yếu tài liệu trả về là định dạng XML .


GET https://final-blade.com/posts
authority: gpcoder.com
Accept: application/xml;q=0.9

Và tài liệu nhận được :



	
		2019/05/20
		Java Web service tutorial
		...
	
	
		2019/05/25
		SOAP Web Service
		...
	
	
		2019/05/30
		RESTful Web Service
		...
	


Sự khác nhau giữa REST và SOAP

SOAP REST
SOAP là viết tắt của Simple Object Access Protocol (Giao thức truy cập đối tượng đơn giản) REST là viết tắt của REpresentational State Transfer (Chuyển giao trạng thái phản hồi)
Một giao thức gửi nhận message có dạng XML. Một loại kiến trúc bao gồm các quy tắc để thao tác với server.
SOAP là một chuẩn được tạo ra để chuẩn hóa giao tiếp giữa client và server về format, structure và method. Sử dụng WSDL để giao tiếp giữa máy chủ và máy khách. SOAP sử dụng các message dạng XML để giao tiếp với server. Sử dụng XML hoặc JSON để gửi nhận dữ liệu.
SOAP sử dụng các message dạng XML để xác định các thủ tục hay tài nguyên yêu cầu. Gọi các service thông qua method RPC. RESTful sử dụng URL để xác định tài nguyên mong muốn được truy cập.
Không dễ đọc. Dễ đọc vì đơn giản chỉ là text XML hoặc JSON.
Có thể truyền qua nhiều giao thức khác nhau như HTTP, SMTP, FTP,… Tuy nhiên trong thực tết chúng ta cũng sử dụng giao thức HTTP nhiều hơn nên lợi thế này của SOAP cũng không mấy được coi trọng. REST chỉ có thể truyền qua HTTP và nó thừa hưởng tất cả những lợi ích của giao thức HTTP, bao gồm các method như GET, POST, PUT và DELETE để thực hiện các hành động truy vấn, thêm, sửa, xóa dữ liệu.
JS có thể dùng để gọi SOAP, nhưng rất khó để làm. Quá đơn giản nếu dùng JS.
Performance không tốt bằng REST. Performance tốt hơn SOAP, tốn ít tài nguyên CPU hơn, code ngắn gọn hơn.
Các message SOAP thường có độ dài và dung lượng cao hơn so với một request của RESTful, do đó nếu dùng SOAP thì bạn sẽ tốn băng thông nhiều hơn. Tốn ít băng thông hơn SOAP.
SOAP cần viết thêm các cơ sở hạ tầng để bảo mật các message và giao thức vận chuyển. RESTful web service có thể được triển khai bằng các giải pháp và tiêu chuẩn truyền thống để các truy cập được phân quyền và xác thực trước khi sử dụng tài nguyên web.
Các dịch vụ web SOAP hoàn toàn bỏ qua caching web. RESTful web service tận dụng tối đa cơ chế caching vì về cơ bản chúng dựa trên URL.
Các dịch vụ web SOAP, mọi thực thể đều tập trung vào các interface và message. Các dịch vụ web dựa trên REST, mọi thực thể đều tập trung vào các tài nguyên

Lý do sử dụng REST thay vì SOAP ?

  • REST có thể được sử dụng bởi bất kỳ client nào ví dụ: Java, C ++, Python client và thậm chí là một trình duyệt web với Ajax và JavaScript.
  • REST nhẹ hơn so với SOAP, nó không yêu cầu phân tích cú pháp XML và nó cũng tiêu tốn ít băng thông hơn vì không giống như SOAP, REST không yêu cầu SOAP header cho mỗi lần request.
  • SOAP là một công nghệ cũ, còn tất cả những gã khổng lồ hiện đại đang sử dụng REST, ví dụ: Google, Twitter và Flickr…
  • REST rất dễ học, nó chỉ cần hiểu danh từ và động từ. Nếu bạn đã biết các phương thức HTTP thì nó thậm chí còn dễ dàng hơn.
  • Java hỗ trợ tuyệt vời cho RESTFul web service và cũng hỗ trợ tốt cho SOAP web service. Bạn có rất nhiều sự lựa chọn ở đây, ví dụ: Jersey, RESTLet, …

Lý do sử dụng SOAP ?

Mặc dù REST có rất nhiều ưu điểm hơn so với SOAP. Tuy nhiên, có một số ít nguyên do hoàn toàn có thể khiến bạn muốn lựa chọn SOAP cho dịch vụ web của mình :

  • WS-Security : SOAP không chỉ hỗ trợ SSL (giống như REST) mà còn hỗ trợ WS-Security, bổ sung thêm một số tính năng enterprise security. Hỗ trợ nhận dạng thông qua các trung gian, không chỉ là point-to-point như SSL. Nó được dùng khi muốn xây dựng những web service đảm bảo và tin cậy. Web Service Security đảm bảo cho tính an toàn, sự toàn vẹn thông điệp và tính tin cậy của thông điệp.
  • WS-AtomicTransaction : Khi muốn có các giao dịch ACID qua một dịch vụ, bạn sẽ phải cần SOAP. Mặc dù REST có hỗ trợ các transactions, nhưng nó không toàn diện và cũng không phù hợp với ACID. REST bị hạn chế bởi HTTP nên không thể cung cấp cam kết hai pha trên các tài nguyên giao dịch phân tán, nhưng SOAP lại có thể àm được điều này. Thật may mắn các giao dịch ACID gần như không có ý nghĩa nhiều đối với các dịch vụ internet thông thường. Nhưng đôi khi các ứng dụng doanh nghiệp lại cần mức độ tin cậy giao dịch này.
  • WS-ReliableMessaging : REST không có hệ thống báo lỗi chuẩn và mong muốn khách hàng giải quyết các lỗi communicate bằng cách retry và … retry … SOAP đã thành công trong việc xử lý những tình huống này và cung cấp end-to-end một cách tin cậy thông qua các trung gian SOAP

SOAP rõ ràng là hữu dụng và quan trọng. Ví dụ, Nếu bạn viết một ứng dụng để tiếp xúc với ngân hàng nhà nước chắc như đinh bạn sẽ cần phải sử dụng SOAP. Tất cả ba tính năng trên là bắt buộc so với những thanh toán giao dịch ngân hàng nhà nước. Ví dụ : nếu tôi chuyển tiền từ thông tin tài khoản này sang thông tin tài khoản khác, tôi cần phải chắc như đinh rằng nó đã hoàn tất. Việc cứ nỗ lực retry thực sự là quá kinh dị nếu thanh toán giao dịch thành công xuất sắc lần tiên phong nhưng thông tin tôi nhận được lại là thất bại .Bài viết khá dài và nặng về kim chỉ nan, hoàn toàn có thể những bạn chưa hiểu được khi lần tiên phong khám phá về web service. Trong những bài viết tiếp theo, tất cả chúng ta sẽ cùng tìm hiểu và khám phá cách kiến thiết xây dựng về SOAP / RESTful web service và cách sử dụng nó, khi đó những bạn sẽ hiểu rõ hơn về những yếu tố đã được trình diễn trong bài viết này .

Tài liệu tham khảo:

5.0

Nếu bạn thấy hay thì hãy chia sẻ bài viết cho mọi người nhé!

Shares

Bình luận

phản hồi