REST có phải là cách tiếp cận tốt hơn để thực hiện các 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.

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ó đang đượ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 mà 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ụ.

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 phong bì SOAP trong ứng dụng REST.

Bản thân SOAP thực sự khá cơ bản và đơn giản, đó là các tiêu chuẩn WSS- * trên đầu trang khiến 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 chỉ là một cú click 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à WSS stack 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.

REST là một mô hình cơ bản khác với SOAP. Có thể đọc một cách hay về REST ở đâ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 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 nơi 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 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 điều này đều 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à một API phức tạp hơn để giao tiếp bằng cách chuyển XML xung quanh. Cả hai đều có những ư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.

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

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

• Băng thông và tài nguyên hạn chế. 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). Thêm vào đó, 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ạt động hoàn toàn phi trạng thái.  Nếu một hoạt động cần được tiếp 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ó 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ó.

• Tình huống bộ nhớ đệm.  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. Điều đó bao gồm rất nhiều giải pháp trong ba cách 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à một cách tiếp cận và rộng mở để 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 hoạt động này. 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.

• Hoạt động nhà nước. Nếu ứng dụng cần thông tin theo ngữ cảnh và quản lý trạng thái đàm 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

XÀ BÔ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.

Kết quả là REST đơn giản hơn, 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 là mở rộng theo 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.

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 Dịch vụ Web đượ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. Các 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 những gì khung SOAP thể hiện. Và, nếu bạn có các con vịt 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 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 để đưa các đặc điểm phát trực tuyến ra khỏi 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 được người tiêu dùng dễ 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 AJAX trên các 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.

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 qua 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ỳ quy mô 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 thứ 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à các lớp và máy khách proxy đầu ra. 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 mà bạn 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à một công cụ không có trí tuệ.

3) Tôi đã nghe khiếu nại rằng với SOAP, bạn có "chi phí chung" của Phong bì SOAP. 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 có thể chỉ cần đư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?

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ố ứng dụng khách 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 như 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.

Tôi khuyên bạn nên đi với REST trước - nếu bạn đang sử dụng Java, hãy xem JAX-RS và triển khai Jersey . 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 luồng 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, WS-Địa chỉ, 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 et al - có xu hướng sử dụng và thích API RESTful hơn các API SOAP.

Một cách tiếp cận thú vị khác 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 ứng dụng web và giao diện 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

Tôi chắc chắn Don Box đã tạo ra 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.

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

SOAP : 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, nơi 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).

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?)

Đừ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 lượng mã tối thiểu. XML-RPC đã xuất hiện được 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 thứ gì đó của sự hồi sinh muộn màng.

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 kết quả ngày hôm nay (các câu trả lời khác).

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

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ả các dịch vụ Web REST bằng WSDL và sử dụng giao thức SOAP ... Đó 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 ra 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"): như được hiển thị bởi L.Mandel , WSDL2 có thể mô tả một dịch vụ web REST 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ỳ dịch vụ web REST nào không thể là SOAP ... Đó là, "90%" của các ví dụ REST nổi tiếng. Một số không sử dụng XML (ví dụ, các AJAX REST điển hình sử dụng JSON thay thế), một số sử dụng các cấu trúc XML khác, không có các tiêu đề hoặc quy tắc SOAP. PS: để tránh sự 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ỳ dịch vụ web SOAP nào không thể là REST ... Đó là, "90%" trong số các ví dụ SOAP được biết đến.

• 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 các điều kiện REST

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 (như "thỏa thuận bằng văn bản"),

  • Bằng cách sử dụng 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ư tô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.

  • 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 xung quanh logic thử lại và do đó có thể cung cấp độ tin cậy đầu cuối và đảm bảo dịch vụ nhiều hơn", E. Terman .

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

• Các công cụ tốt hơn (~ 70 phiếu): SOAP hiện có lợi thế của các công cụ tốt hơn, kể từ năm 2007 và vẫn là năm 2012, vì đây 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ủ tiêu chuẩn (25 phiếu): như tô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 các tiêu đề SOAP, @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ột số mức độ không thích với sự dư thừa và phức tạp của SOAP. Đâ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 sự mạnh mẽ (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 . Điểm này được thể hiện bởi @toluju (41) và những người khác.
  PS: vì 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 bằng các so sánh NON-SOAP-REST và giải thích khi nào nê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 "Nhu cầu B2B tiêu chuẩn" đượ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ý song song nặng (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ể phức tạp hơn một chút về SOAP, độ tin cậy và ổn định là những khoản đầu tư tốt nhấ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 @Bell , 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 XML Encryption , XML Chữ ký , và XML Canonicalization , và, chỉ với SOAP bạn có thể nhúng các cơ chế này vào một tin nhắn bằng một tiêu chuẩn được chấp nhận như 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 xác minh chính thức : quan trọng để hiểu rằng ngăn xếp W3C sử dụng các phương thức chính thức và REST là không chính thức. Mô tả dịch vụ WSDL ( ngôn ngữ chính thức ) của bạn là một đặc điểm kỹ thuật chính thức của cá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ả các đơn thuốc WSDL có thể.

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 ngăn xếp W3C 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à các "trình phát phần mềm Web" lớn, như Google, Amazon, Yahoo, et al, đã bầu ra phương án tốt nhất, đó là phương pháp REST. Có phải trong bối cảnh này, khái niệm REST đã xuất hiện như một "khung cạnh tranh" và, ngày nay (2012), sự thay thế này là một 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ụ" nào: các 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.

Đó 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 có 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.

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 nhau .

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 có chứa mô tả về 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 về 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. đối với REST, không yêu cầu phần mềm trung gian chỉ cần hỗ trợ HTTP. Tiêu chuẩn WADL, 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 đó 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 có xử lý lỗi
6. REST đặc biệt hữu ích 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. Các dịch vụ Web SOAP (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 SOAP của API phức tạp sẽ hữu ích hơn.

REST là một kiến ​​trúc được phát minh bởi Roy Fielding và được mô tả trong luận án 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 các dịch vụ Web REST", 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 ra 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.

Tôi đang xem xét cùng một vấn đề. Dường như với tôi rằng REST thực sự 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 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 đó, các dịch vụ web dựa trên REST tiêu thụ rất nhiều 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 để phù hợp với các cuộc gọi có thể. Tạo 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 tài nguyên logic của họ để đặt ra bất kỳ thay đổi nào đối với giao diện sẽ thay đổi wsdl. Không có chỗ 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 để giải thích và thay đổi có vẻ như là một ý tưởng tồi.

'Trả lời' hàng đầu 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.

Đó 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ĩ.

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.

Nguyên 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 một quy trình 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, nói chung là quá phức tạp cho những gì nó làm trừ khi nó được trình bày trong bối cảnh cung cấp một máy API có thể đọc chi tiết các chức năng cụ thể với các định dạng dữ liệu được đặt cho đầu vào và đầu ra, đến lượt nó, được viết theo kịch bản bởi một 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 lợi thế của SOAP mà không trình bày nó trong bối cảnh đầy đủ về cách sử dụng sản phẩm cuối cùng.

SOAP 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 có một 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.

Theo nghĩa với hỗ trợ PHP "vũ trụ PHP" cho bất kỳ SOAP nâng cao nào đều 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 Mã hóa SOAP (Chúa biết nó khác nhau như thế nào) trong các thông báo SOAP.

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 mà chúng tôi đã sử dụng nó kể từ khi bắt đầu WWW. Chúng tôi chỉ nhận ra khi http://www.ics.uci.edu/~fielding/pub/dissertation/top.htm xuất hiện trên giấy 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ế, bạn chưa nghe nói về tiêu đề SOAP Action chưa? Nếu không phải là google ngay bây giờ!).

Với việc tăng cường thích ứng JSON và HTML5 với javascript trưởng thành 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ợ SOAP hiện có mà 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 này, tôi rất thích SOAP, đặc biệt là với đặc tả 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.

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

Tôi sử dụng SOAP qua 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ì).

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 hoạt động giữa .NET và Java chẳng hạn.

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

Một câu hỏi cũ nhưng vẫn còn liên quan đến ngày hôm nay .... do có 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òn có hỗ trợ REST trong suốt Azure. Nếu tôi cần 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.

1. Từ kinh nghiệm của tôi. Tôi muốn nói REST cung cấp cho bạn tùy chọn để truy cập URL đã được xây dựng. ví dụ:> một tìm kiếm từ 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 ứng dụng khách SOAP.

2. 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.