Ưu và nhược điểm của WSDL vs REST

Có liên quan:

Tại sao người ta sử dụng REST thay vì các dịch vụ Web?

Khi quyết định triển khai một dịch vụ web sử dụng SOAP hay REST (ý tôi là HTTP / XML theo cách RESTful) tôi nên biết điều gì và tôi nên nghĩ đến điều gì? Tôi cho rằng đây không phải là một kích thước phù hợp với tất cả mọi thứ, vậy làm cách nào để tôi chọn cái nào để sử dụng.

Hai giao thức có cách sử dụng rất khác nhau trong thế giới thực.

SOAP (sử dụng WSDL) là một tiêu chuẩn XML có trọng lượng lớn tập trung vào việc truyền tài liệu. Ưu điểm của điều này là các yêu cầu và phản hồi của bạn có thể được cấu trúc rất tốt và thậm chí có thể sử dụng DTD. Nhược điểm là nó là XML, và rất dài dòng. Tuy nhiên, điều này là tốt nếu hai bên cần có một hợp đồng chặt chẽ (ví dụ như giao tiếp liên ngân hàng). SOAP cũng cho phép bạn xếp lớp những thứ như WS-Security trên tài liệu của mình. SOAP nói chung là giao thông bất khả tri, có nghĩa là bạn không nhất thiết phải sử dụng HTTP.

REST rất nhẹ và dựa trên tiêu chuẩn HTTP để hoạt động. Thật tuyệt khi có được một dịch vụ web hữu ích và chạy nhanh chóng. Nếu bạn không cần định nghĩa API nghiêm ngặt, đây là cách để thực hiện. Hầu hết các dịch vụ web đều thuộc loại này. Bạn có thể phiên bản API của mình để các bản cập nhật cho API không bị hỏng đối với những người sử dụng phiên bản cũ (miễn là họ chỉ định một phiên bản). REST về cơ bản yêu cầu HTTP và là định dạng bất khả tri (nghĩa là bạn có thể sử dụng XML, JSON, HTML, bất cứ thứ gì).

Nói chung, tôi sử dụng REST, vì tôi không cần các tính năng WS- * ưa thích. Tuy nhiên, SOAP là tốt nếu bạn muốn máy tính hiểu dịch vụ web của bạn bằng cách sử dụng WSDL. Thông số kỹ thuật REST thường chỉ con người mới có thể đọc được.

Các liên kết sau cung cấp thông tin hữu ích về WSDL vs REST bao gồm cả Ưu và nhược điểm

Một vài điểm chính là

1) SOAP được thiết kế cho một môi trường máy tính phân tán trong đó REST được thiết kế cho một môi trường điểm tới điểm.

2) WADL có thể được sử dụng để xác định giao diện cho các dịch vụ REST.

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and -wadl

Về WSDL (có nghĩa là "SOAP") là "nặng ký". Vấn đề nặng như thế nào? Nếu bộ công cụ đang làm tất cả những công việc "nặng nhọc" cho bạn, thì tại sao nó lại quan trọng?

Tôi chưa bao giờ cần sử dụng một API REST phức tạp. Khi tôi làm vậy, tôi hy vọng tôi sẽ mong muốn có một WSDL, mà các công cụ của tôi sẽ sẵn sàng chuyển đổi thành một tập hợp các lớp proxy, vì vậy tôi có thể chỉ cần gọi những gì có vẻ là các phương thức. Thay vào đó, tôi nghi ngờ rằng để sử dụng một API dựa trên REST không tầm thường, cần phải viết bằng tay một lượng đáng kể mã "trọng lượng nhẹ".

Ngay cả khi mọi việc đã hoàn tất, bạn vẫn sẽ dịch tài liệu có thể đọc được của con người sang mã, với tất cả rủi ro là con người đọc sai. Vì WSDL là mô tả dịch vụ có thể đọc được bằng máy, nên việc "đọc nhầm" sẽ khó hơn nhiều.

Chỉ cần lưu ý: kể từ bài đăng này, tôi đã có cơ hội làm việc với một dịch vụ REST phức tạp vừa phải. Tôi thực sự mong muốn có một WSDL hoặc tương đương, và tôi đã thực sự phải viết rất nhiều mã bằng tay. Trên thực tế, một phần đáng kể của thời gian phát triển đã được dành để loại bỏ sự trùng lặp mã của tất cả các mã được gọi là các hoạt động dịch vụ khác nhau "bằng tay".

Điều này có thể thực sự thuộc về các bình luận trong một số bài viết ở trên, nhưng tôi chưa có đại diện để làm điều đó, vì vậy hãy tiếp tục.

Tôi nghĩ điều thú vị là rất nhiều ưu và nhược điểm thường được trích dẫn cho SOAP và REST (IMO) rất ít liên quan đến các giá trị hoặc giới hạn thực tế của hai công nghệ. Có lẽ chuyên gia được trích dẫn nhiều nhất cho REST là nó "nhẹ" hoặc có xu hướng "con người dễ đọc" hơn. Ở một cấp độ, điều này chắc chắn đúng, REST có rào cản gia nhập thấp hơn - có cấu trúc ít bắt buộc hơn SOAP (mặc dù tôi đồng ý với những người đã nói rằng công cụ tốt phần lớn là câu trả lời ở đây - công cụ SOAP quá tệ là khá ghê).

Tuy nhiên, ngoài chi phí nhập ban đầu đó, tôi nghĩ rằng ấn tượng REST đến từ sự kết hợp giữa dạng URL yêu cầu và độ phức tạp của dữ liệu được trao đổi bởi hầu hết các dịch vụ REST. REST có xu hướng khuyến khích các URL yêu cầu đơn giản hơn, con người dễ đọc hơn và dữ liệu cũng có xu hướng dễ tiêu hóa hơn. Tuy nhiên, những điều này vốn có đối với REST ở mức độ nào và ở mức độ nào chúng chỉ là tình cờ. Cấu trúc URL đơn giản hơn là kết quả trực tiếp của kiến ​​trúc - nhưng nó có thể được áp dụng tốt như nhau cho các dịch vụ dựa trên SOAP. Dữ liệu dễ tiêu hóa hơn có nhiều khả năng là kết quả của việc thiếu bất kỳ cấu trúc xác định nào. Điều này có nghĩa là bạn nên giữ cho các định dạng dữ liệu của mình đơn giản hoặc bạn sẽ phải làm rất nhiều việc. Vì vậy, đây là cấu trúc bổ sung của SOAP,

Vì vậy, để sử dụng trong việc trao đổi dữ liệu có cấu trúc giữa các hệ thống máy tính, tôi không chắc rằng REST vốn đã tốt hơn SOAP (hoặc thị thực - ngược lại), chúng chỉ khác nhau. Tôi nghĩ rằng so sánh ở trên của REST vs SOAP để nhập động và tĩnh là một sự so sánh tốt. Nơi mà các ngôn ngữ dyanmic có xu hướng gặp rắc rối là việc bảo trì và duy trì hệ thống trong thời gian dài (và về lâu dài, tôi không nói một hoặc 2 năm, tôi đang nói 5 hoặc 10). Sẽ rất thú vị để xem liệu REST có gặp phải những thách thức tương tự theo thời gian hay không. Tôi có xu hướng nghĩ rằng nó sẽ như vậy nếu tôi đang xây dựng một hệ thống xử lý thông tin, phân tán, tôi sẽ sử dụng SOAP làm cơ chế giao tiếp (cũng vì phân lớp giao thức truyền và ứng dụng và tính linh hoạt mà nó mang lại như đã được đề cập ở trên).

Ở những nơi khác, mặc dù REST có vẻ thích hợp hơn. AJAX giữa máy khách và máy chủ của nó (bất kể trọng tải) là một ví dụ chính. Tôi không quan tâm nhiều đến tuổi thọ của loại kết nối này và tính dễ sử dụng và tính linh hoạt đang ở mức thấp. Tương tự như vậy, nếu tôi cần truy cập nhanh vào một số dịch vụ bên ngoài và tôi không nghĩ rằng mình sẽ quan tâm đến khả năng duy trì của tương tác theo thời gian (một lần nữa tôi cho rằng đây là nơi REST sẽ khiến tôi phải trả nhiều tiền hơn, một cách hoặc khác), thì tôi có thể chọn REST chỉ để tôi có thể ra vào nhanh chóng.

Dù sao, cả hai đều là công nghệ khả thi và tùy thuộc vào sự cân bằng mà bạn muốn thực hiện cho một ứng dụng nhất định mà chúng có thể phục vụ bạn tốt (hoặc kém).

REST không phải là một giao thức; Đó là một phong cách kiến ​​trúc. Hoặc một mô hình nếu bạn muốn. Điều đó có nghĩa là việc định nghĩa SOAP là lỏng lẻo hơn rất nhiều. Đối với CRUD cơ bản, bạn có thể dựa vào các giao thức tiêu chuẩn như Atompub, nhưng đối với hầu hết các dịch vụ, bạn sẽ có nhiều lệnh hơn thế.

Là một người tiêu dùng, SOAP có thể là một phước lành hoặc một lời nguyền, tùy thuộc vào sự hỗ trợ của ngôn ngữ. Vì SOAP được mô phỏng rất nhiều trên một hệ thống được đánh máy nghiêm ngặt, nên nó hoạt động tốt nhất với các ngôn ngữ được gõ tĩnh. Đối với một ngôn ngữ động, nó có thể dễ dàng trở nên thô và thừa. Ngoài ra, hỗ trợ thư viện khách không phải là tốt bên ngoài thế giới của Java và .NET

Đối với tôi, chúng ta nên cẩn thận khi sử dụng từ dịch vụ web. Lúc nào chúng ta cũng nên chỉ rõ nếu chúng ta đang nói về dịch vụ web SOAP, dịch vụ web REST hay các loại dịch vụ web khác bởi vì chúng ta đang nói về những thứ khác nhau ở đây và mọi người không hiểu nữa nếu chúng ta đặt tên cho tất cả chúng là dịch vụ web.

Về cơ bản các dịch vụ web SOAP được thiết lập rất tốt trong nhiều năm và chúng tuân theo một đặc điểm kỹ thuật nghiêm ngặt mô tả cách giao tiếp với chúng dựa trên đặc điểm kỹ thuật SOAP. Giờ đây, các dịch vụ web REST đã mới hơn một chút và về cơ bản trông đơn giản hơn vì chúng không sử dụng bất kỳ giao thức truyền thông nào. Về cơ bản, những gì bạn gửi và nhận khi sử dụng dịch vụ web REST là XML thuần túy. Mọi người thích nó vì họ có thể phân tích cú pháp xml theo cách họ muốn mà không cần phải xử lý một giao thức truyền thông phức tạp hơn như SOAP.

Đối với tôi, các dịch vụ REST gần giống như nếu bạn tạo một servlet thay vì một dịch vụ web SOAP. Servlet nhận dữ liệu vào và trả dữ liệu ra. Định dạng của dữ liệu dựa trên xml. Chúng ta cũng có thể tưởng tượng để sử dụng thứ gì đó khác ngoài xml nếu chúng ta muốn. Ví dụ: thẻ có thể được sử dụng thay vì xml và đó sẽ không phải là REST nữa mà là một cái gì đó khác (Có thể nhẹ hơn về trọng lượng vì bản chất xml không nhẹ). Chúng tôi sẽ gọi đó vẫn là một dịch vụ web? Có, chúng ta có thể nhưng điều đó sẽ không tuân theo bất kỳ tiêu chuẩn hiện tại nào và đây là vấn đề chính ở đây nếu chúng ta bắt đầu gọi mọi thứ là dịch vụ web nhưng chúng ta có thể làm theo cách chúng ta muốn thì chúng ta đang đánh mất khía cạnh tương tác của mọi thứ. Điều đó có nghĩa là định dạng của dữ liệu được trao đổi với dịch vụ web không được chuẩn hóa nữa.

Điều mọi người không thích với SOAP là họ khó hiểu nó và họ không thể tạo các truy vấn theo cách thủ công. Tuy nhiên, máy tính có thể làm điều đó rất tốt vì vậy đây là lúc chúng ta cần phải làm rõ: các truy vấn và phản hồi dịch vụ web được cho là được sử dụng trực tiếp bởi người dùng cuối hay chúng tôi đồng ý rằng các dịch vụ web nằm bên dưới API được gọi bởi hệ thống máy tính dựa trên một số tiêu chuẩn?

SOAP : Nó cũng có thể được vận chuyển qua SMTP, có nghĩa là chúng tôi có thể gọi dịch vụ bằng cách sử dụng Email định dạng văn bản đơn giản

Nó cần thêm khuôn khổ / công cụ phải có trong máy tiêu dùng dịch vụ web để chuyển đổi thông điệp SOAP sang cấu trúc đối tượng tương ứng bằng nhiều ngôn ngữ khác nhau.

NGHỈ NGƠI : Giờ đây WSDL2.0 cũng hỗ trợ mô tả dịch vụ web REST

Chúng tôi có thể sử dụng khi bạn muốn làm cho dịch vụ của mình trở nên nhẹ nhàng, ví dụ như gọi điện từ các thiết bị di động như điện thoại di động, pda, v.v.

đối với các hệ thống doanh nghiệp trong đó hệ thống của bạn bị giới hạn trong các công ty của bạn, việc sử dụng xà phòng dễ dàng và thích hợp hơn vì bạn gần như kiểm soát được khách hàng. dễ dàng hơn vì có nhiều công cụ tạo các lớp (proxy) và có vẻ như bạn đang thực hiện OOP thông thường, phù hợp với môi trường java hoặc .net của bạn (trong đó hầu hết các công ty sử dụng).

Tôi sẽ sử dụng REST cho các ứng dụng đối mặt với internet để hiển thị giao diện (như twitter api) vì khách hàng có thể đang sử dụng javascrip hoặc html hoặc các ứng dụng khác mà việc nhập không nghiêm ngặt. REST tự do hơn sẽ có ý nghĩa hơn.

Ngoài ra đối với các khách hàng sử dụng internet (web trên toàn thế giới), việc phân tích cú pháp json hoặc xml ra khỏi giao diện nghỉ ngơi dễ dàng hơn là xml thuần túy đến từ giao diện xà phòng. thật khó để sử dụng proxy trên javascript và javascript không hỗ trợ các đối tượng một cách tự nhiên. Nếu bạn đang sử dụng REST với javascript, bạn thường chỉ phân tích cú pháp chuỗi json và bạn đã tắt. giao diện đối mặt với internet thường rất đơn giản (vì vậy hầu hết thời gian phân tích cú pháp đơn giản của nó) và thường không yêu cầu tính nhất quán, đó là lý do tại sao REST là đủ.

Đối với các ứng dụng doanh nghiệp, tôi không nghĩ REST là phù hợp vì các giao dịch, bảo mật, đánh máy nghiêm ngặt, các lược đồ đóng vai trò rất quan trọng trong việc phát triển các ứng dụng doanh nghiệp, đó là lý do tại sao SOAP phù hợp hơn với chúng.

Kết luận của tôi là SOAP dành cho hệ thống Doanh nghiệp, REST dành cho Internet hoặc WWW. Bạn có thể sử dụng nó thay thế cho nhau nhưng cuối cùng bạn có thể thấy mình gặp khó khăn khi không sử dụng đúng công cụ cho công việc.

Xin lỗi vì tiếng Anh của tôi không tốt.

Để bảo vệ REST, nó tuân thủ chặt chẽ các nguyên tắc của HTTP và khả năng định địa chỉ, ví dụ: thao tác đọc sử dụng GET, thao tác cập nhật sử dụng POST, v.v. Tôi thấy đây là một cách tiếp cận rõ ràng hơn nhiều. Cuốn sách Oreilly RESTful Web Services giải thích điều này tốt hơn nhiều so với những gì tôi có thể, nếu bạn đọc nó, tôi nghĩ bạn sẽ thích cách tiếp cận REST hơn

Bộ công cụ ở phía khách hàng sẽ là một. Và sự quen thuộc với các dịch vụ SOAP khác. Ngày càng có nhiều dịch vụ đi theo lộ trình RESTful ngày nay và việc thử nghiệm các dịch vụ như vậy có thể được thực hiện với các ví dụ cURL đơn giản. Mặc dù, không khó để triển khai cả hai phương pháp và cho phép khách hàng sử dụng rộng rãi nhất.

Nếu bạn cần chọn một cái, tôi đề xuất REST, nó dễ dàng hơn.

Các câu trả lời trước đây chứa đựng rất nhiều thông tin, nhưng tôi nghĩ rằng có một sự khác biệt triết học chưa được chỉ ra. SOAP là câu trả lời cho "làm thế nào để chúng tôi tạo ra một phiên bản hiện đại, hướng đối tượng, nền tảng và giao thức độc lập với RPC?". REST được phát triển từ câu hỏi, "làm thế nào để chúng tôi có được những thông tin chi tiết đã làm nên thành công của HTTP cho web và sử dụng chúng cho máy tính phân tán?"

SOAP là cung cấp cho bạn các công cụ để làm cho lập trình phân tán trông giống như ... lập trình. REST cố gắng áp đặt một phong cách để đơn giản hóa các giao diện phân tán, để các tài nguyên phân tán có thể tham chiếu đến nhau như các trang html phân tán có thể tham chiếu đến nhau. Một cách nó thực hiện đó là cố gắng (hầu hết) hạn chế các hoạt động thành "CRUD" trên tài nguyên (tạo, đọc, cập nhật, xóa).

REST vẫn còn non trẻ - mặc dù nó hướng tới các dịch vụ "con người có thể đọc được", nhưng nó không loại trừ các dịch vụ xem xét nội tâm, v.v. hoặc tự động tạo proxy. Tuy nhiên, những điều này chưa được tiêu chuẩn hóa (như tôi viết). SOAP cung cấp cho bạn những thứ này, nhưng (IMHO) cung cấp cho bạn "chỉ" những thứ này, trong khi phong cách do REST áp đặt đã khuyến khích sự phổ biến của các dịch vụ web vì tính đơn giản của nó. Bản thân tôi sẽ khuyến khích các nhà cung cấp dịch vụ mới chọn REST trừ khi có các tính năng cụ thể do SOAP cung cấp mà họ cần sử dụng.

Theo ý kiến ​​của tôi, sau đó, nếu bạn đang triển khai API "greenfield" và không biết nhiều về các ứng dụng khách có thể có, tôi sẽ chọn REST vì phong cách mà nó khuyến khích có xu hướng giúp làm cho giao diện dễ hiểu và dễ phát triển. Nếu bạn biết nhiều về máy khách và máy chủ, và có các công cụ SOAP cụ thể sẽ giúp cuộc sống của cả hai trở nên dễ dàng, thì tôi sẽ không tôn trọng REST.

Bạn có thể dễ dàng chuyển đổi các thành phần web WCF phun WSDL của mình sang các mục đích sử dụng khác chỉ bằng cách thay đổi cài đặt cấu hình của bạn. Bạn có thể đi qua HTTP và sau đó cũng có tên đường ống, tcp, giao thức tùy chỉnh, v.v. mà không cần phải thay đổi mã của bạn. Tôi tin rằng các thành phần WCF cũng có thể dễ dàng thiết lập hơn cho những thứ như bảo mật, gọi hai chiều, giao dịch, đồng thời, v.v.

REST giới hạn bạn khá nhiều với HTTP (điều này tốt trong nhiều trường hợp).

Tôi biết rằng cuộc thảo luận này là một cuộc thảo luận cũ, nhưng sau khi đọc tất cả các câu trả lời và nhận xét, tôi tin rằng mọi người đã bỏ lỡ điểm quan trọng nhất về sự khác biệt giữa 2 hệ thống: SOAP sử dụng các kiểu phức tạp để không chỉ cung cấp cho bạn dữ liệu mà còn xác thực nó và giữ nó trong ký hiệu loại nghiêm ngặt mà nó đã được xác định. WSDL cho bạn biết định dạng dữ liệu là gì, kiểu dữ liệu là gì, cho phép bạn thêm các quy tắc kiểu mẫu reg-ex và xác định số lần một phần dữ liệu phải được và có thể được phép trong một yêu cầu / phản hồi . Mặt khác, phần còn lại không có cơ chế nào trong số này.

SOAP phức tạp và nặng nề vì nó cho phép bạn gửi dữ liệu phân cấp phức tạp. REST là văn bản thuần túy, với điểm gốc và điểm cuối sắp xếp theo các quy tắc.

SOAP độc lập với doanh nghiệp, bởi vì nó có tất cả các quy tắc dữ liệu được nhúng trong tài liệu.

Sự khác biệt giữa SOAP và REST là SOAP là một lược đồ định hướng kinh doanh khép kín. REST là một tài liệu văn bản.