it-swarm-vi.tech

SOAP hoặc REST cho Dịch vụ web?

REST là cách tiếp cận tốt hơn để thực hiện Dịch vụ web hay là SOAP? Hay chúng là những công cụ khác nhau cho các vấn đề khác nhau? Hay đó là một vấn đề sắc thái - nghĩa là, một trong những đấu trường nhất định tốt hơn một chút, v.v.?

Tôi đặc biệt đánh giá cao thông tin về các khái niệm đó và mối quan hệ của chúng với vũ trụ PHP và các ứng dụng web cao cấp hiện đại.

378
user13276

Tôi đã xây dựng một trong những máy chủ SOAP đầu tiên, bao gồm tạo mã và tạo WSDL, từ thông số ban đầu khi nó được phát triển, khi tôi đang làm việc tại Hewlett-Packard. Tôi KHÔNG khuyên bạn nên sử dụng SOAP cho bất cứ điều gì.

Từ viết tắt "SOAP" là một lời nói dối. Nó không đơn giản, nó không hướng đối tượng, nó xác định không có quy tắc Access. Nó được cho là một Nghị định thư. Đó là thông số tồi tệ nhất từ ​​trước đến nay của Don Box, và đó là một kỳ tích, vì anh ta là người đã thực hiện "COM".

Không có gì hữu ích trong SOAP không thể thực hiện được với REST để truyền tải và JSON, XML hoặc thậm chí là văn bản thuần túy để biểu diễn dữ liệu. Để bảo mật vận chuyển, bạn có thể sử dụng https. Để xác thực, xác thực cơ bản. Đối với phiên, có cookie. Phiên bản REST sẽ đơn giản hơn, rõ ràng hơn, chạy nhanh hơn và sử dụng ít băng thông hơn.

XML-RPC xác định rõ ràng các giao thức yêu cầu, phản hồi và lỗi và có các thư viện tốt cho hầu hết các ngôn ngữ. Tuy nhiên, XML nặng hơn bạn cần cho nhiều nhiệm vụ.

560
mdhughes

REST là một kiến ​​trúc, SOAP là một giao thức.

Đó là vấn đề đầu tiên.

Bạn có thể gửi SOAP phong bì trong ứng dụng REST.

Bản thân SOAP thực sự khá cơ bản và đơn giản, chính các tiêu chuẩn WSS- * ở trên nó làm cho nó rất phức tạp.

Nếu khách hàng của bạn là các ứng dụng khác và các máy chủ khác, có rất nhiều hỗ trợ cho giao thức SOAP ngày nay và những điều cơ bản của việc di chuyển dữ liệu về cơ bản là nhấp chuột trong các IDE hiện đại.

Nếu người tiêu dùng của bạn có nhiều khả năng là khách hàng RIA hoặc Ajax, có lẽ bạn sẽ muốn một cái gì đó đơn giản hơn SOAP và có nguồn gốc hơn từ máy khách (đặc biệt là JSON).

Các gói JSON được gửi qua HTTP không nhất thiết phải là kiến ​​trúc REST, nó chỉ là các thông báo tới URL. Tất cả đều hoàn toàn khả thi, nhưng có các thành phần chính cho thành ngữ REST. Tuy nhiên, rất dễ nhầm lẫn giữa hai. Nhưng chỉ vì bạn đang nói các yêu cầu HTTP không nhất thiết có nghĩa là bạn có kiến ​​trúc REST. Bạn có thể có một ứng dụng REST hoàn toàn không có HTTP (xin lỗi, điều này rất hiếm).

Vì vậy, nếu bạn có máy chủ và người tiêu dùng "thoải mái" với SOAP, SOAP và ngăn xếp WSS có thể phục vụ tốt cho bạn. Nếu bạn đang làm nhiều thứ đặc biệt hơn và muốn giao diện tốt hơn với các trình duyệt web, thì một số giao thức nhẹ hơn qua HTTP cũng có thể hoạt động tốt.

197
Will Hartung

REST là một mô hình khác biệt cơ bản với SOAP. Bạn có thể tìm thấy một cách tốt về REST tại đây: Cách tôi giải thích REST với vợ tôi .

Nếu bạn không có thời gian để đọc nó, thì đây là phiên bản ngắn: REST là một chút thay đổi mô hình bằng cách tập trung vào "danh từ" và hạn chế số lượng "động từ" bạn có thể áp dụng cho những động từ đó danh từ Các động từ được phép duy nhất là "get", "put", "post" và "xóa". Điều này khác với SOAP trong đó nhiều động từ khác nhau có thể được áp dụng cho nhiều danh từ khác nhau (nghĩa là nhiều chức năng khác nhau).

Đối với REST, bốn động từ ánh xạ tới các yêu cầu HTTP tương ứng, trong khi các danh từ được xác định bởi các URL. Điều này làm cho việc quản lý trạng thái trở nên minh bạch hơn nhiều so với trong SOAP, nơi nó thường không rõ trạng thái nào trên máy chủ và máy khách là gì.

Trong thực tế, mặc dù hầu hết những thứ này biến mất và REST thường chỉ đề cập đến các yêu cầu HTTP đơn giản trả về kết quả trong JSON , trong khi SOAP là nhiều hơn API phức tạp giao tiếp bằng cách chuyển XML xung quanh. Cả hai đều có ưu điểm và nhược điểm, nhưng tôi thấy rằng theo kinh nghiệm của mình REST thường là lựa chọn tốt hơn bởi vì bạn hiếm khi cần đến chức năng đầy đủ mà bạn có được từ SOAP.

102
toluju

Hạ thấp nhanh chóng cho câu hỏi năm 2012:

Các khu vực mà REST hoạt động thực sự tốt là:

  • Băng thông và tài nguyên bị giới hạn. Hãy nhớ cấu trúc trả về thực sự ở bất kỳ định dạng nào (nhà phát triển xác định). Ngoài ra, bất kỳ trình duyệt nào cũng có thể được sử dụng vì cách tiếp cận REST sử dụng các động từ GET, PUT, POST và DELETE tiêu chuẩn. Một lần nữa, hãy nhớ rằng REST cũng có thể sử dụng đối tượng XMLHttpRequest mà hầu hết các trình duyệt hiện đại hỗ trợ hiện nay, điều này bổ sung thêm phần thưởng AJAX.

  • Hoàn toàn không hoạt động. Nếu cần tiếp tục thao tác, thì REST không phải là cách tiếp cận tốt nhất và SOAP có thể phù hợp với nó tốt hơn. Tuy nhiên, nếu bạn cần các thao tác CRUD (Tạo, Đọc, Cập nhật và Xóa) không trạng thái, thì REST chính là nó.

  • Các tình huống lưu trữ. Nếu thông tin có thể được lưu trong bộ nhớ cache do hoạt động hoàn toàn không trạng thái của phương pháp REST, thì điều này là hoàn hảo. rất nhiều giải pháp trong ba điều trên.

Vậy tại sao tôi thậm chí sẽ xem xét SOAP? Một lần nữa, SOAP khá trưởng thành và được xác định rõ ràng và đi kèm với một đặc điểm kỹ thuật hoàn chỉnh. Cách tiếp cận REST chỉ là cách tiếp cận và mở rộng để phát triển, vì vậy nếu bạn có những điều sau đây thì SOAP là một giải pháp tuyệt vời:

  • Xử lý và gọi không đồng bộ. Nếu ứng dụng của bạn cần mức độ tin cậy và bảo mật được đảm bảo thì SOAP 1.2 cung cấp các tiêu chuẩn bổ sung để đảm bảo loại này hoạt động. Những thứ như WSRM - Nhắn tin đáng tin cậy WS.

  • Hợp đồng chính thức. Nếu cả hai bên (nhà cung cấp và người tiêu dùng) phải đồng ý về định dạng trao đổi thì SOAP 1.2 đưa ra các thông số kỹ thuật cứng nhắc cho loại tương tác này.

  • Các hoạt động có trạng thái. Nếu ứng dụng cần thông tin theo ngữ cảnh và quản lý trạng thái hội thoại thì SOAP 1.2 có đặc tả bổ sung trong cấu trúc WS * để hỗ trợ những thứ đó (Bảo mật, Giao dịch, Phối hợp, v.v.). Một cách tương đối, cách tiếp cận REST sẽ khiến các nhà phát triển xây dựng hệ thống ống nước tùy chỉnh này.

http://www.infoq.com/articles/rest-soap-when-to-use-each

59
PmanAce

XÀ PHÒNG hiện có lợi thế của các công cụ tốt hơn, nơi họ sẽ tạo ra rất nhiều mã soạn sẵn cho cả lớp dịch vụ cũng như tạo các máy khách từ bất kỳ WSDL nào.

REST đơn giản hơn, do đó có thể dễ dàng duy trì hơn, nằm ở trung tâm của kiến ​​trúc Web, cho phép hiển thị giao thức tốt hơn và đã được chứng minh ở quy mô của chính WWW. Một số khung công tác giúp bạn xây dựng các dịch vụ REST, như Ruby on Rails, và một số thậm chí còn giúp bạn viết các ứng dụng khách, như Dịch vụ dữ liệu ADO.NET. Nhưng đối với hầu hết các phần, hỗ trợ công cụ là thiếu.

44
Mark Cidade

SOAP rất hữu ích từ góc độ công cụ vì WSDL rất dễ bị các công cụ tiêu thụ. Vì vậy, bạn có thể nhận các ứng dụng khách Web Service được tạo cho bạn bằng ngôn ngữ yêu thích của bạn.

REST chơi tốt với các trang web AJAX'y. Nếu bạn giữ các yêu cầu của mình đơn giản, bạn có thể thực hiện các cuộc gọi dịch vụ trực tiếp từ JavaScript của mình và điều đó rất hữu ích. Cố gắng tránh xa bất kỳ không gian tên nào trong XML phản hồi của bạn, tôi đã thấy các trình duyệt bị sặc trên đó. Vì vậy, xsi: type có thể sẽ không hiệu quả với bạn, không có Lược đồ XML quá phức tạp.

REST có xu hướng có hiệu suất tốt hơn là tốt. Yêu cầu CPU của mã tạo ra các phản hồi REST có xu hướng thấp hơn so với khung SOAP trưng bày. Và, nếu bạn có các thế hệ XML của bạn được xếp hàng ở phía máy chủ, bạn có thể truyền XML ra máy khách một cách hiệu quả. Vì vậy, hãy tưởng tượng bạn đang đọc các hàng của con trỏ cơ sở dữ liệu. Khi bạn đọc một hàng, bạn định dạng nó dưới dạng một phần tử XML và bạn viết nó trực tiếp ra cho người tiêu dùng dịch vụ. Theo cách này, bạn không phải thu thập tất cả các hàng cơ sở dữ liệu trong bộ nhớ trước khi bắt đầu viết đầu ra XML của mình - bạn đọc và viết cùng một lúc. Nhìn vào các công cụ tạo khuôn mẫu mới hoặc XSLT để truyền phát hoạt động cho REST.

Mặt khác, SOAP có xu hướng được tạo ra bởi các dịch vụ do công cụ tạo ra như một đốm lớn và chỉ sau đó được viết. Đây không phải là một sự thật tuyệt đối, hãy nhớ, có nhiều cách để có được các đặc điểm phát trực tuyến từ SOAP, như bằng cách sử dụng tệp đính kèm.

Quá trình ra quyết định của tôi như sau: nếu tôi muốn dịch vụ của mình dễ dàng được người tiêu dùng sử dụng và các tin nhắn tôi viết sẽ ở mức trung bình đến nhỏ (10MB trở xuống) và tôi không ngại đốt thêm một số CPU chu kỳ trên máy chủ, tôi đi với SOAP. Nếu tôi cần phân phát tới AJAX trên trình duyệt web hoặc tôi cần điều đó để phát trực tuyến hoặc phản hồi của tôi là khổng lồ, tôi đi REST.

Cuối cùng, có rất nhiều tiêu chuẩn tuyệt vời được xây dựng xung quanh SOAP, như WS-Security và nhận các Dịch vụ Web trạng thái, mà bạn có thể cắm vào nếu bạn đang sử dụng đúng công cụ. Loại công cụ đó thực sự tạo ra sự khác biệt, và có thể giúp bạn đáp ứng một số yêu cầu về lông.

40
Dave Woldrich

Tôi biết đây là một câu hỏi cũ nhưng tôi phải đăng câu trả lời của mình - có thể ai đó sẽ thấy nó hữu ích. Tôi không thể tin có bao nhiêu người đang giới thiệu REST trên SOAP. Tôi chỉ có thể giả sử những người này không phải là nhà phát triển hoặc chưa bao giờ thực sự triển khai dịch vụ REST với bất kỳ kích thước hợp lý nào. Việc triển khai dịch vụ REST mất nhiều thời gian hơn so với triển khai dịch vụ SOAP. Và cuối cùng, nó cũng xuất hiện nhiều rắc rối hơn. Dưới đây là những lý do tôi sẽ chọn SOAP 99% thời gian:

1) Việc triển khai dịch vụ REST mất nhiều thời gian hơn so với triển khai dịch vụ SOAP. Các công cụ tồn tại cho tất cả các ngôn ngữ/khung/nền tảng hiện đại để đọc trong WSDL và xuất các lớp và máy khách proxy. Việc triển khai dịch vụ REST được thực hiện bằng tay và - có được điều này - bằng cách đọc tài liệu. Hơn nữa, trong khi thực hiện hai dịch vụ này, bạn phải đưa ra "dự đoán" về những gì sẽ quay trở lại qua đường ống vì không có lược đồ hoặc tài liệu tham khảo thực sự.

2) Tại sao lại viết một dịch vụ REST trả về XML? Sự khác biệt duy nhất là với REST bạn không biết các loại mà mỗi phần tử/thuộc tính đại diện - bạn tự mình thực hiện nó và hy vọng rằng một ngày nào đó một chuỗi không xuất hiện trong một lĩnh vực bạn suy nghĩ luôn luôn là một int. SOAP xác định cấu trúc dữ liệu bằng WSDL, vì vậy đây là công cụ không có trí tuệ.

3) Tôi đã nghe thấy khiếu nại rằng với SOAP bạn có "chi phí" của SOAP Phong bì. Trong thời đại ngày nay, chúng ta có thực sự cần phải lo lắng về một số byte không?

4) Tôi đã nghe lập luận rằng với REST bạn chỉ có thể đưa URL vào trình duyệt và xem dữ liệu. Chắc chắn, nếu dịch vụ REST của bạn đang sử dụng đơn giản hoặc không có xác thực. Ví dụ, dịch vụ Netflix sử dụng OAuth yêu cầu bạn ký tên và mã hóa mọi thứ trước khi bạn có thể gửi yêu cầu của mình.

5) Tại sao chúng ta cần một URL "có thể đọc" cho mỗi tài nguyên? Nếu chúng tôi đang sử dụng một công cụ để triển khai dịch vụ, chúng tôi có thực sự quan tâm đến URL thực tế không?

Cần tôi tiếp tục?

29
Josh M.

Hầu hết các ứng dụng tôi viết là C # hoặc Java phía máy chủ hoặc các ứng dụng máy tính để bàn trong WinForms hoặc WPF. Các ứng dụng này có xu hướng cần API dịch vụ phong phú hơn REST có thể cung cấp. Ngoài ra, tôi không muốn mất hơn một vài phút để tạo ứng dụng khách dịch vụ web của mình. Các công cụ tạo ứng dụng khách xử lý WSDL cho phép tôi triển khai ứng dụng khách của mình và chuyển sang thêm giá trị doanh nghiệp.

Bây giờ, nếu tôi đang viết một dịch vụ web rõ ràng cho một số cuộc gọi ajax javascript, thì nó có thể nằm trong REST; chỉ vì muốn biết công nghệ máy khách và tận dụng JSON. Theo tôi, API dịch vụ web được sử dụng từ javascript có lẽ không nên quá phức tạp, vì loại phức tạp đó dường như được xử lý tốt hơn phía máy chủ.

Như đã nói, có một số khách hàng SOAP cho javascript; Tôi biết jQuery có một cái. Do đó, SOAP có thể được tận dụng từ javascript; không độc đáo bằng dịch vụ REST trả về chuỗi JSON. Vì vậy, nếu tôi có một dịch vụ web mà tôi muốn đủ phức tạp để nó linh hoạt với số lượng công nghệ và sử dụng máy khách tùy ý, tôi sẽ sử dụng SOAP.

19
Travis Heseman

Trước tiên, tôi khuyên bạn nên đi với REST - nếu bạn đang sử dụng Java, hãy xem JAX-RS và Jersey triển khai. REST đơn giản hơn nhiều và dễ dàng xen vào nhiều ngôn ngữ.

Như những người khác đã nói trong chủ đề này, vấn đề với SOAP là sự phức tạp của nó khi các thông số kỹ thuật WS- * khác xuất hiện và có vô số vấn đề xen kẽ nếu bạn đi lạc vào các phần sai của WSDL, XSD, SOAP, Địa chỉ WS, v.v.

Cách tốt nhất để đánh giá cuộc tranh luận REST v SOAP là tìm trên internet - khá nhiều người chơi lớn trong không gian web, google, Amazon, ebay, Twitter và cộng sự để sử dụng và thích các API RESTful hơn các SOAP.

Một cách tiếp cận Nice khác để thực hiện với REST là bạn có thể sử dụng lại rất nhiều mã và cơ cấu hạ tầng giữa một ứng dụng web và giao diện người dùng REST. ví dụ. hiển thị HTML so với XML so với JSON của tài nguyên của bạn thường khá dễ dàng với các khung như JAX-RS và các chế độ xem ẩn - cộng với việc dễ dàng làm việc với các tài nguyên RESTful bằng trình duyệt web

17
James Strachan

Tôi chắc chắn Don Box đã tạo SOAP như một trò đùa - 'nhìn bạn có thể gọi các phương thức RPC qua web' và hôm nay rên rỉ khi anh ấy nhận ra cơn ác mộng phình to của các tiêu chuẩn web đã trở thành :-)

REST tốt, đơn giản, được triển khai ở mọi nơi (vì vậy nhiều 'tiêu chuẩn' hơn tiêu chuẩn) nhanh chóng và dễ dàng. Sử dụng REST.

16
gbjbaanb

Tôi nghĩ rằng cả hai đều có vị trí riêng của mình. Theo ý kiến ​​của tôi:

XÀ PHÒNG: Một lựa chọn tốt hơn để tích hợp giữa các hệ thống kế thừa/quan trọng và hệ thống dịch vụ web/web, trên lớp nền tảng, trong đó WS- * có ý nghĩa (bảo mật, chính sách, v.v.).

RESTful: Một lựa chọn tốt hơn để tích hợp giữa các trang web, với API công khai, trên TOP của lớp (VIEW, tức là, javascripts nhận cuộc gọi đến URI).

15
irobson

Một điều chưa được đề cập là một phong bì SOAP có thể chứa các tiêu đề cũng như các bộ phận cơ thể. Điều này cho phép bạn sử dụng toàn bộ tính biểu cảm của XML để gửi và nhận thông tin về băng tần. REST, theo như tôi biết, giới hạn bạn ở Tiêu đề HTTP và mã kết quả.

(otoh, bạn có thể sử dụng cookie với dịch vụ REST để gửi "tiêu đề" ra khỏi dữ liệu băng tần không?)

13
John Saunders

Trả lời câu hỏi 2012 được làm mới (bằng tiền thưởng thứ hai) và xem xét các kết quả ngày hôm nay (các câu trả lời khác).


SOAP, ưu và nhược điểm

Giới thiệu về SOAP 1.2, ưu điểm và nhược điểm khi so sánh với "REST" ... Chà, kể từ năm 2007 bạn có thể mô tả REST Dịch vụ web với WSDL và sử dụng SOAP giao thức ... Nghĩa là, nếu bạn làm việc chăm chỉ hơn một chút, tất cả các tiêu chuẩn W3C của ngăn xếp giao thức dịch vụ web có thể là REST !

Đó là một điểm khởi đầu tốt, bởi vì chúng ta có thể tưởng tượng một kịch bản trong đó tất cả các cuộc thảo luận triết học và phương pháp học tạm thời được tránh. Chúng tôi có thể so sánh về mặt kỹ thuật "SOAP-REST" với "NON-SOAP-REST" trong các dịch vụ tương tự,

  • SOAP-REST (= "REST-SOAP"): as hiển thị bởi L.Mandel , WSDL2 có thể mô tả một REST dịch vụ web và, nếu chúng tôi cho rằng XML được minh họa có thể được bao bọc trong SOAP, tất cả việc triển khai sẽ là "SOAP-REST".

  • NON-SOAP-REST : bất kỳ REST dịch vụ web không thể là SOAP ... Nghĩa là, "90%" trong số các ví dụ REST được nhiều người biết đến. Một số không sử dụng XML (ví dụ điển hình AJAX REST sử dụng JSON thay thế), một số sử dụng cấu trúc XML khác, không có tiêu đề hoặc quy tắc SOAP. PS: để tránh tính không chính thức, chúng ta có thể giả sử REST cấp 2 trong các so sánh.

Tất nhiên, để so sánh một cách khái niệm hơn, hãy so sánh "NON-REST-SOAP" với "NON-SOAP-REST", như các phương pháp mô hình hóa khác nhau. Vì vậy, hoàn thành phân loại dịch vụ web này:

  • NON-REST-SOAP : bất kỳ SOAP dịch vụ web không thể là REST ... Đó là, "90%" trong số các ví dụ SOAP được biết nhiều.

  • NON-REST-NEITHER-SOAP : vâng, vũ trụ của "mô hình hóa dịch vụ web" bao gồm những thứ khác (ví dụ XML-RPC ).

SOAP trong REST kết án

So sánh những thứ có thể so sánh: SOAP-REST với NON-SOAP-REST .

PROS

Giải thích một số điều khoản,

  • Ổn định hợp đồng : cho tất cả các loại hợp đồng (dưới dạng "thỏa thuận bằng văn bản"),

    • Bằng cách sử dụng của các tiêu chuẩn : tất cả các cấp của ngăn xếp W3C đều tuân thủ lẫn nhau. Mặt khác, REST không phải là tiêu chuẩn W3C hoặc ISO và không có chi tiết được chuẩn hóa về các thiết bị ngoại vi của dịch vụ. Vì vậy, như I , @DaveWoldrich (20 phiếu), @cynicalman (5), @Exitos (0) đã nói trước đó, trong bối cảnh CẦN PHẢI TIÊU CHUẨN, bạn cần SOAP.

    • Bằng cách sử dụng các thực tiễn tốt nhất : "khía cạnh dài dòng" của việc triển khai ngăn xếp W3C , dịch các thỏa thuận về con người/pháp lý/pháp lý có liên quan .

  • Tính mạnh mẽ : sự an toàn của cấu trúc và tiêu đề SOAP. Với giao tiếp metada (với tính biểu cảm đầy đủ của XML) và xác minh bạn có "chính sách bảo hiểm" chống lại mọi thay đổi hoặc tiếng ồn.
    [.__.] SOAP có "độ tin cậy giao dịch (...) đối phó với các lỗi giao tiếp. SOAP có nhiều kiểm soát hơn về logic thử lại và do đó có thể cung cấp độ tin cậy và bảo đảm dịch vụ từ đầu đến cuối nhiều hơn", - E. Terman .

Sắp xếp ưu điểm theo mức độ phổ biến,

  • Công cụ tốt hơn (~ 70 phiếu): SOAP hiện có lợi thế của công cụ tốt hơn, kể từ năm 2007 và vẫn là năm 2012, bởi vì đó là một tiêu chuẩn được xác định rõ và được chấp nhận rộng rãi. Xem @MarkCidade (27 phiếu), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9).

  • Tuân thủ theo tiêu chuẩn (25 phiếu): as I , @DaveWoldrich (20 phiếu), @cynicalman (5), @Exitos (0) đã nói trước đây, trong bối cảnh CẦN PHẢI TIÊU CHUẨN, bạn cần SOAP.

  • Tính mạnh mẽ : bảo hiểm của SOAP tiêu đề, @JohnSaunders (8 phiếu).

TIÊU DÙNG

  • Cấu trúc SOAP phức tạp hơn (hơn 300 phiếu): tất cả các câu trả lời ở đây và các nguồn về "SOAP vs REST", biểu hiện mức độ không thích với SOAP dư thừa và phức tạp. Đây là kết quả tự nhiên của các yêu cầu đối với xác minh chính thức (xem bên dưới) và cho độ mạnh (xem ở trên). "REST NON-SOAP" (và XML-RPC, người khởi tạo SOAP ) có thể đơn giản và không chính thức hơn.

  • Hạn chế "chỉ XML" là một trở ngại về hiệu suất khi sử dụng các dịch vụ nhỏ (~ 50 phiếu): xem json.org/xml = và câu hỏi này , hoặc câu hỏi khác này . Điểm này được thể hiện bởi @toluju (41) và những người khác.
    [.__.] PS: as JSON không phải là tiêu chuẩn IETF , nhưng chúng ta có thể xem xét một tiêu chuẩn thực tế cho cộng đồng phần mềm web.


Dịch vụ lập mô hình với SOAP

Bây giờ, chúng ta có thể thêm SOAP-NON-REST với NON-SOAP-REST so sánh và giải thích khi nào tốt hơn để sử dụng SOAP :

  • Cần các tiêu chuẩn và hợp đồng ổn định (xem phần "PROS"). PS: xem một "B2B cần tiêu chuẩn" điển hình được mô tả bởi @saille .

  • Cần cho các công cụ (xem phần "PROS"). PS: tiêu chuẩn và sự tồn tại của xác minh chính thức (xem dưới đây), là những vấn đề quan trọng đối với tự động hóa công cụ.

  • Xử lý nặng song song (xem phần "Bối cảnh/Cơ sở" bên dưới): với các quy trình lớn hơn và/hoặc chậm hơn, bất kể SOAP phức tạp hơn một chút, độ tin cậy và ổn định là tốt nhất đầu tư.

  • Cần bảo mật hơn : khi cần nhiều hơn HTTPS và bạn thực sự cần các tính năng bổ sung để bảo vệ, SOAP là lựa chọn tốt hơn ( xem @ Chuông , 32 phiếu). "Gửi tin nhắn dọc theo một đường dẫn phức tạp hơn yêu cầu/phản hồi hoặc qua một phương tiện giao thông không liên quan đến HTTP", S. Seely . XML là một vấn đề cốt lõi, cung cấp các tiêu chuẩn cho Mã hóa XML , Chữ ký XML XML Canonicalization và, chỉ với SOAP bạn có thể nhúng các cơ chế này vào tin nhắn theo một tiêu chuẩn được chấp nhận tốt là WS-Security .

  • Cần linh hoạt hơn (ít hạn chế hơn): SOAP không cần sự tương ứng chính xác với URI; không giới hạn cho HTTP; không cần giới hạn ở 4 động từ. Như @TravisHeseman (9 phiếu) nói, nếu bạn muốn một cái gì đó "linh hoạt cho một số lượng công nghệ và sử dụng khách hàng tùy ý", hãy sử dụng SOAP.
    [.__.] PS: hãy nhớ rằng XML phổ quát/biểu cảm hơn JSON (et al).

  • Cần cho xác minh chính thức: quan trọng để hiểu rằng Ngăn xếp W3C sử dụng phương thức chính thức và REST không chính thức hơn. Mô tả dịch vụ WSDL (a ngôn ngữ chính thức ) của bạn là đặc tả chính thức giao diện dịch vụ web của bạn và SOAP là một giao thức mạnh mẽ chấp nhận tất cả WSDL có thể đơn thuốc.

BỐI CẢNH

Lịch sử

Để đánh giá xu hướng là quan điểm lịch sử cần thiết. Đối với chủ đề này, viễn cảnh 10 hoặc 15 năm ...

Trước khi tiêu chuẩn hóa W3C, có một số tình trạng hỗn loạn. Rất khó để thực hiện các dịch vụ có thể tương tác với các khung khác nhau và khó khăn hơn, tốn kém và mất thời gian hơn để thực hiện một cái gì đó có thể tương tác giữa các công ty. Các tiêu chuẩn W3C stack là một ánh sáng, một hướng bắc cho sự tương tác của các bộ dịch vụ web phức tạp.

Đối với các nhiệm vụ hàng ngày, muốn triển khai AJAX, SOAP rất nặng ... Vì vậy, nhu cầu về các phương pháp đơn giản cần phải chọn một khung lý thuyết mới ... Và những "người chơi phần mềm Web" lớn , như Google, Amazon, Yahoo, et al, đã bầu ra phương án thay thế tốt nhất, đó là cách tiếp cận REST. Có phải trong bối cảnh này, khái niệm REST đã xuất hiện dưới dạng "khung cạnh tranh" và, ngày nay (2012), sự thay thế này là tiêu chuẩn thực tế cho các lập trình viên.

Nền móng

Trong ngữ cảnh Tính toán song song , các dịch vụ web cung cấp các nhiệm vụ song song; và các giao thức, như SOAP, đảm bảo đồng bộ hóa và giao tiếp tốt. Không phải "bất kỳ nhiệm vụ": dịch vụ web có thể được phân loại là
[.__.] song song thô và lúng túng .

Khi nhiệm vụ trở nên lớn hơn, nó trở nên ít "tranh luận phức tạp" hơn, và trở nên phù hợp hơn với sự mạnh mẽ của giao tiếp và sự vững chắc của các hợp đồng.

10
Peter Krauss

Đừng bỏ qua XML-RPC. Nếu bạn chỉ sau một giải pháp nhẹ thì sẽ có rất nhiều điều đáng nói về một giao thức có thể được xác định trong một vài trang văn bản và được triển khai trong một số lượng mã tối thiểu. XML-RPC đã xuất hiện trong nhiều năm nhưng đã lỗi thời trong một thời gian - nhưng sự hấp dẫn tối giản dường như mang lại cho nó một cái gì đó của sự hồi sinh muộn.

10
Cruachan

Đó là sắc thái.

Nếu bạn cần có giao diện hệ thống khác với các dịch vụ của mình, nhiều khách hàng sẽ hài lòng hơn với SOAP, do các lớp "xác minh" bạn có với các hợp đồng, WSDL và tiêu chuẩn SOAP.

Đối với các hệ thống hàng ngày gọi vào các hệ thống, tôi nghĩ rằng SOAP là rất nhiều chi phí không cần thiết khi một cuộc gọi HTML đơn giản sẽ thực hiện.

9
cynicalman

Tôi đang nhìn giống nhau, và tôi nghĩ, chúng là những công cụ khác nhau cho các vấn đề khác nha.

Giao thức truy cập đối tượng đơn giản (SOAP) là ngôn ngữ XML xác định kiến ​​trúc thông báo và định dạng thông báo, được sử dụng bởi các dịch vụ Web chứa mô tả các hoạt động. 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. sẽ chạy trên SMTP, HTTP, FTP, v.v. Yêu cầu hỗ trợ phần mềm trung gian, cơ chế được xác định rõ để xác định các dịch vụ như WSDL + XSD, WS-Policy SOAP sẽ trả về dữ liệu dựa trên XML SOAP cung cấp các tiêu chuẩn cho bảo mật và độ tin cậy

Dịch vụ web chuyển giao nhà nước đại diện (RESTful). chúng là dịch vụ web thế hệ thứ hai. Các dịch vụ web RESTful, giao tiếp qua HTTP hơn các dịch vụ dựa trên SOAP và không yêu cầu các thông báo XML hoặc định nghĩa API dịch vụ WSDL. for REST không yêu cầu phần mềm trung gian chỉ cần hỗ trợ HTTP.WADL Standard, REST có thể trả về XML, văn bản thuần túy, JSON, HTML, v.v.

Nhiều loại máy khách sẽ dễ dàng sử dụng các dịch vụ web RESTful hơn trong khi cho phép phía máy chủ phát triển và mở rộng quy mô. Khách hàng có thể chọn sử dụng một số hoặc tất cả các khía cạnh của dịch vụ và kết hợp nó với các dịch vụ dựa trên web khác.

  1. REST sử dụng HTTP tiêu chuẩn để đơn giản hóa việc tạo ứng dụng khách, phát triển API
  2. REST cho phép nhiều định dạng dữ liệu khác nhau như XML, văn bản thuần túy, JSON, HTML trong đó as SOAP chỉ cho phép XML.
  3. REST có hiệu suất và khả năng mở rộng tốt hơn.
  4. Nghỉ ngơi và có thể được lưu trữ và SOAP không thể
  5. Xử lý lỗi tích hợp trong đó SOAP không xử lý lỗi
  6. REST đặc biệt hữu ích PDA và các thiết bị di động khác.

REST là dịch vụ dễ dàng tích hợp với các trang web hiện có.

SOAP đã thiết lập các giao thức, cung cấp các tiêu chuẩn về bảo mật và độ tin cậy, trong số những thứ khác, và tương tác với các máy khách và máy chủ tuân thủ WS khác. SOAP Các dịch vụ web (như JAX-WS) rất hữu ích trong việc xử lý việc gọi và xử lý không đồng bộ.

Đối với API phức tạp SOAP sẽ hữu ích hơn.

9
kapil das

REST là một kiến ​​trúc được phát minh bởi Roy Fielding và được mô tả trong luận án của mình Phong cách kiến ​​trúc và Thiết kế Kiến trúc phần mềm dựa trên mạng . Roy cũng là tác giả chính của HTTP - giao thức xác định chuyển tài liệu qua World Wide Web. HTTP là một giao thức RESTful. Khi các nhà phát triển nói về "sử dụng REST Dịch vụ web", có lẽ chính xác hơn để nói "sử dụng HTTP".

SOAP là một giao thức dựa trên XML có đường hầm bên trong một yêu cầu/phản hồi HTTP, vì vậy ngay cả khi bạn sử dụng SOAP, bạn cũng đang sử dụng REST. Có một số tranh luận về việc liệu SOAP có thêm bất kỳ chức năng quan trọng nào vào HTTP cơ bản hay không.

Trước khi tạo một dịch vụ Web, tôi khuyên bạn nên nghiên cứu HTTP. Vấn đề là các yêu cầu của bạn có thể được thực hiện với chức năng đã được xác định trong thông số kỹ thuật, vì vậy các giao thức khác sẽ không cần thiết.

8
Chris Broski

Tôi đang xem xét cùng một vấn đề. Dường như với tôi rằng thực sự REST là nhanh chóng và dễ dàng và tốt cho các cuộc gọi và phản hồi nhẹ và tuyệt vời để gỡ lỗi (điều gì có thể tốt hơn là bơm URL vào trình duyệt và xem phản hồi).

Tuy nhiên, nơi REST dường như rơi xuống là do thực tế rằng nó không phải là một tiêu chuẩn (mặc dù nó bao gồm các tiêu chuẩn). Hầu hết các thư viện lập trình đều có cách kiểm tra WSDL để tự động tạo mã máy khách cần thiết để sử dụng các dịch vụ dựa trên SOAP. Do đó, việc sử dụng nhiều dịch vụ web dựa trên REST dường như là một cách tiếp cận đặc biệt hơn trong việc viết giao diện để khớp với các cuộc gọi có thể. Thực hiện một yêu cầu http thủ công sau đó phân tích cú pháp phản hồi. Điều này tự nó có thể nguy hiểm.

Cái hay của SOAP là một khi WSDL được phát hành thì doanh nghiệp 'có thể cấu trúc aorund logic của họ để đặt hợp đồng bất kỳ thay đổi nào lên giao diện sẽ thay đổi wsdl. Không có bất kỳ phòng cho manouvre. Bạn có thể xác nhận tất cả các yêu cầu đối với WSDL đó. Tuy nhiên, vì WSDL không mô tả đúng dịch vụ REST nên bạn không có cách xác định đồng ý trên giao diện để liên lạc.

Từ góc độ kinh doanh, điều này dường như để lại sự giao tiếp mở cho việc giải thích và thay đổi có vẻ như là một ý tưởng tồi.

'Trả lời' trên cùng trong chủ đề này dường như nói rằng SOAP là viết tắt của Giao thức truy cập hướng đối tượng đơn giản, tuy nhiên nhìn vào wiki thì O có nghĩa là Đối tượng không hướng đối tượng. Chúng là những thứ khác nhau.

Tôi biết bài này rất cũ nhưng nghĩ rằng tôi nên trả lời với những phát hiện của riêng tôi.

7
Exitos

Đó là một câu hỏi hay ... Tôi không muốn dẫn bạn đi lạc đường, vì vậy tôi cởi mở với câu trả lời của người khác nhiều như bạn. Đối với tôi, nó thực sự phụ thuộc vào chi phí hoạt động và việc sử dụng API là gì. Tôi thích tiêu thụ các dịch vụ web khi tạo phần mềm máy khách, tuy nhiên tôi không thích trọng lượng của SOAP. REST, tôi tin rằng, trọng lượng nhẹ hơn nhưng tôi không thích làm việc với nó từ góc độ khách hàng gần như nhiều.

Tôi tò mò về những gì người khác nghĩ.

6
cranley

Nghe podcast này để tìm hiểu. Nếu bạn muốn biết câu trả lời mà không cần nghe, thì OK, REST của nó. Nhưng tôi thực sự khuyên bạn nên lắng nghe.

6
Mark Beckwith

Quy tắc chung của tôi là nếu bạn muốn một ứng dụng web trình duyệt kết nối trực tiếp với một dịch vụ thì có lẽ bạn nên sử dụng REST. Nếu bạn muốn truyền dữ liệu có cấu trúc giữa các dịch vụ back-end thì hãy sử dụng SOAP.

SOAP có thể là một nỗi đau thực sự để thiết lập đôi khi và thường là quá mức cần thiết cho việc trao đổi dữ liệu máy khách và máy chủ web đơn giản. Thật không may, hầu hết các ví dụ lập trình đơn giản mà tôi đã thấy (và học được từ) phần nào tái hiện nhận thức này.

Điều đó nói rằng, SOAP thực sự tỏa sáng khi bạn bắt đầu kết hợp nhiều dịch vụ SOAP với nhau như một phần của quy trình lớn hơn được điều khiển bởi luồng công việc dữ liệu (nghĩ phần mềm doanh nghiệp). Đây là điều mà nhiều ví dụ lập trình SOAP không thể truyền tải được vì một thao tác SOAP đơn giản để làm một cái gì đó, như lấy giá của một cổ phiếu, thường bị áp đặt quá mức cho những gì nó làm chính nó trừ khi nó được trình bày trong bối cảnh cung cấp API có thể đọc chi tiết các chức năng cụ thể của máy với các định dạng dữ liệu được đặt cho các đầu vào và đầu ra, đến lượt nó, được viết theo quy trình lớn hơn.

Điều này thật đáng buồn, theo một cách nào đó, vì nó thực sự mang lại cho SOAP tiếng xấu vì khó thể hiện những ưu điểm của SOAP mà không trình bày trong bối cảnh đầy đủ về cách sản phẩm cuối cùng Được sử dụng.

6
Rick Sarvas

Theo nghĩa với "PHP-vũ trụ" PHP hỗ trợ cho mọi nâng cao SOAP hút thời gian lớn. Cuối cùng, bạn sẽ sử dụng một cái gì đó như http://wso2.com/products/web-service-framework/php/ ngay khi bạn vượt qua các nhu cầu cơ bản, thậm chí để bật WS-Security hoặc WS- RM không hỗ trợ sẵn có.

Tạo phong bì SOAP Tôi cảm thấy rất lộn xộn trong PHP, cách nó tạo ra các không gian tên, xsd: nil, xsd: anytype và các dịch vụ xà phòng kiểu cũ sử dụng SOAP Mã hóa (Chúa biết nó khác nhau như thế nào) trong SOAP tin nhắn.

Tránh tất cả mớ hỗn độn này bằng cách bám vào REST, REST không có gì thực sự lớn chúng tôi đã sử dụng nó kể từ khi bắt đầu WWW. Chúng tôi chỉ nhận ra khi điều này http://www.ics.uci.edu/~fielding/pub/dissertation/top.htmlm giấy xuất hiện cho thấy cách chúng tôi có thể sử dụng các khả năng HTTP để triển khai Dịch vụ RESTFul. HTTP vốn là REST, điều đó không có nghĩa là chỉ sử dụng HTTP sẽ tạo ra các dịch vụ RESTFul của bạn.

SOAP bỏ qua các khả năng cốt lõi của HTTP và coi HTTP giống như một giao thức vận chuyển, do đó về mặt lý thuyết là giao thức vận chuyển (trong thực tế không phải là trường hợp bạn đã nghe nói về SOAP Tiêu đề hành động? !).

Với sự thích ứng JSON ngày càng tăng và HTML5 với sự trưởng thành của javascript REST với JSON đã trở thành cách xử lý phổ biến nhất đối với các dịch vụ. Lược đồ JSON cũng đã được xác định có thể được sử dụng cho các giải pháp cấp doanh nghiệp (vẫn ở giai đoạn đầu) cùng với WADL nếu cần.

Hỗ trợ PHP cho REST và JSON chắc chắn tốt hơn so với hỗ trợ sẵn có SOAP hiện có.

Thêm một vài từ BUZZ nữa tại đây, SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribed.com/doc/15657444/REST-White-Paper

bằng cách tôi yêu SOAP đặc biệt là đối với thông số WS-Security, đây là một thông số tốt và nếu ai đó nghĩ về sự thích ứng JSON của doanh nghiệp chắc chắn cần phải đi kèm với một số thứ tương tự cho JSON, như mã hóa mức trường, v.v. .

4
shivaspk

XÀ PHÒNG thể hiện cách tiếp cận hướng dịch vụ đối với các dịch vụ Web - một trong đó các phương thức (hoặc động từ) là cách chính mà bạn tương tác với dịch vụ. REST lấy cách tiếp cận hướng tài nguyên trong đó đối tượng (hoặc danh từ) chiếm vị trí trung tâm.

4
Vibha Sanskrityayan

Một điểm nhanh - giao thức truyền và điều phối;

Tôi sử dụng SOAP over TCP vì lý do tốc độ, độ tin cậy và bảo mật, bao gồm cả máy được phối hợp cho các dịch vụ máy (ESB) và cho các dịch vụ bên ngoài. Thay đổi định nghĩa dịch vụ, việc điều phối phát sinh lỗi từ thay đổi WSDL và ngay lập tức rõ ràng và có thể được xây dựng lại/triển khai.

Không chắc chắn bạn có thể làm tương tự với REST - Tôi đang chờ được sửa chữa hoặc khóa học! Với REST, thay đổi định nghĩa dịch vụ - không có gì biết về nó cho đến khi trả về 400 (hoặc bất cứ điều gì).

3
BlueChippy

Nếu bạn đang tìm kiếm khả năng tương tác giữa các hệ thống và ngôn ngữ khác nhau, tôi chắc chắn sẽ đi đến REST. Tôi đã có rất nhiều vấn đề khi cố gắng để SOAP làm việc giữa .NET và Java chẳng hạn.

2
neu242

tôi tạo một điểm chuẩn để tìm ra cái nào nhanh hơn! tôi thấy kết quả này:

cho 1000 yêu cầu:

  • REST mất 3 giây
  • SOAP mất 7 giây

cho 10.000 yêu cầu:

  • REST mất 33 giây
  • SOAP mất 69 giây

cho 1.000.000 yêu cầu:

  • REST mất 62 giây
  • SOAP mất 114 giây
2
Sonador

Một câu hỏi cũ nhưng vẫn còn liên quan đến ngày hôm nay .... do rất nhiều nhà phát triển trong không gian doanh nghiệp vẫn sử dụng nó.

Công việc của tôi liên quan đến việc thiết kế và phát triển các giải pháp IoT (Internet of Things). Bao gồm phát triển mã cho các thiết bị nhúng nhỏ giao tiếp với Đám mây.

Rõ ràng REST hiện được chấp nhận rộng rãi và hữu ích, và khá nhiều tiêu chuẩn defacto cho web, thậm chí Microsoft có hỗ trợ REST trong Azure. Nếu tôi cần phải dựa vào SOAP Tôi không thể làm những gì tôi cần làm, vì nó quá lớn, cồng kềnh và gây khó chịu cho các thiết bị nhúng nhỏ.

REST đơn giản và sạch sẽ và nhỏ. Làm cho nó lý tưởng cho các thiết bị nhúng nhỏ. Tôi luôn hét lên khi tôi làm việc với một nhà phát triển web gửi cho tôi một WSDL. Vì tôi sẽ phải bắt đầu một chiến dịch giáo dục về lý do tại sao điều này sẽ không hiệu quả và tại sao họ sẽ phải học REST.

0
Remixed123

1. Từ kinh nghiệm của tôi. Tôi sẽ nói REST cung cấp cho bạn tùy chọn để truy cập URL đã được tạo. ví dụ:> một tìm kiếm Word trong google. URL đó có thể được sử dụng làm dịch vụ web cho REST. Trong SOAP, bạn có thể tạo dịch vụ web của riêng mình và truy cập thông qua SOAP client.

  1. REST hỗ trợ văn bản, JSON, định dạng XML. Do đó linh hoạt hơn để giao tiếp giữa hai ứng dụng. Trong khi SOAP chỉ hỗ trợ định dạng XML để liên lạc bằng tin nhắn.
0
Shalini Baranwal