Các yếu tố quyết định trong việc lựa chọn đưa ra một dịch vụ web là dịch vụ SOAP hoặc REST là gì?

Theo như tôi có thể thấy việc tiêu thụ SOAP đòi hỏi một ngăn xếp SOAP, do đó khách hàng của bạn khó tiêu thụ hơn, nghĩa là họ cần đảm bảo rằng họ có một ngăn xếp SOAP đúng định dạng dữ liệu POST và các tiêu đề và sau đó trả lại cho bạn một số cấu trúc dữ liệu, trong khi với REST, bạn chỉ cần tạo một yêu cầu HTTP GET với các đối số trong chuỗi truy vấn và nhận lại một số văn bản mà tôi đoán có lẽ là XML.

Vậy SOAP cung cấp cho bạn những gì, khi nào bạn cần nó và khi nào bạn có thể và bạn nên làm gì nếu không có nó?

Tôi đã triển khai API REST trước đây và tôi thực sự thích nó. Nói chung khi bạn triển khai REST qua SOAP, máy khách / máy chủ của bạn có nghĩa trực giao hơn , bạn có thể tự do thay đổi máy chủ nhiều hơn mà không ảnh hưởng đến (các) máy khách của bạn. Tính trực giao này là do sử dụng một giao tiếp trừu tượng hơn và đã được xác định rõ hơn thông qua các động từ HTTP. Ngoài ra, việc sử dụng các siêu liên kết được nhúng trong các phản hồi REST của bạn giúp mở rộng và phát triển API của bạn tương đối dễ dàng hơn. Khách hàng phải theo các liên kết được nhúng này để đến các tài nguyên mới như con người sẽ theo các liên kết trên trang web để 'đi sâu vào' để biết thêm thông tin.

Như đã nói, tôi đã có một số đồng nghiệp được thông báo rằng họ phải sử dụng SOAP và họ đã phàn nàn về điều đó mọi lúc. Vì vậy, tôi đã đi vào nghiên cứu hai chi tiết hơn một chút.

Nói chung những gì tôi thấy là REST rất phù hợp cho các ứng dụng phân tán cao , khi bạn có hàng trăm, hàng ngàn hoặc hàng triệu khách hàng . Một lý do là tính trực giao được đề cập ở trên, một lý do khác là bộ nhớ đệm mà bạn nhận được miễn phí vì bạn đang sử dụng HTTP.

SOAP có thể là cách nhanh hơn để đi khi bạn cần một API nhỏ hơn cho một hoặc hai khách hàng một cách nhanh chóng và bạn không quá lo lắng về khả năng mở rộng. Nó cũng có thể phù hợp với bạn hơn nếu bạn không có kiến ​​trúc được cấu trúc xung quanh các tài nguyên , bởi vì có thể bạn sẽ mất một thời gian để cơ cấu lại ứng dụng của mình để thậm chí có thể triển khai REST.

Nó có thể là một điểm nhỏ, nhưng REST hoàn toàn dựa trên HTTP.

SOAP không yêu cầu HTTP và bạn có thể tự do sử dụng bất kỳ phương tiện giao thông nào bạn muốn.

Các thông điệp SOAP có thể được định tuyến không đồng bộ và đáng tin cậy trong khi REST gần như là một mô hình đồng bộ.

REST không cho bạn biết bất cứ điều gì về dữ liệu bạn đang gửi và nhận sẽ trông như thế nào. Có WADL, nhưng chủ yếu là bạn dựa vào tài liệu về API là chính xác. SOAP có rạp xiếc của các công nghệ XML để làm cho mô tả dữ liệu ít bị lỗi hơn. WSDL, Lược đồ ...

Vào cuối ngày, REST về cơ bản sẽ cung cấp cho bạn một hệ thống tệp dựa trên HTTP. Nếu hệ thống của bạn có thể phù hợp với mô hình đó - thì đó có thể là một lựa chọn tốt.

Vậy SOAP cung cấp cho bạn những gì, khi nào bạn cần nó và khi nào bạn có thể và bạn nên làm gì nếu không có nó?

Sự khác biệt lớn nhất giữa hai loại này là REST được cho là không trạng thái, trong khi SOAP thì không . Trong thực tế, nhiều triển khai REST thực sự thực hiện một số trạng thái trong phiên thông qua một cái gì đó như OAuth.

Một điểm khác biệt nữa là REST rất "tài nguyên" hoặc định hướng danh từ . Bạn tương tác với các tài nguyên thông qua các hoạt động CRUD. Bất cứ điều gì không phù hợp với mô hình này đều trở nên cồng kềnh và vụng về.

Mặt khác, SOAP chỉ là một giao thức RPC (gọi thủ tục từ xa) . Nó không đi kèm với một mô hình, nó chỉ là lớp vận chuyển.

REST cũng sử dụng bài viết. Trong thực tế khi sử dụng REST, các động từ http cho bạn biết hoạt động nào đang diễn ra.

REST và SOAP chỉ là các tiêu chuẩn khác nhau của việc truyền dữ liệu qua internet.

Đã sử dụng cả hai, tôi thường khuyên bạn nên sử dụng REST thay vì SOAP trừ khi bạn biết những người sẽ sử dụng dịch vụ web của bạn đang sử dụng .net và Visual Studio. Việc sử dụng một dịch vụ web REST thường dễ dàng hơn nhiều ngoại trừ với .net VS, công việc này hầu hết cho bạn khi sử dụng SOAP.

Một điều tôi sẽ đề cập là khả năng tương tác - nếu bạn sẽ gọi dịch vụ của mình từ một ứng dụng được viết bằng .NET và máy chủ được viết bằng Java (hoặc bất kỳ sự kết hợp nào khác) thì hãy đến REST. Tôi đã thấy quá nhiều sự không tương thích giữa các triển khai SOAP để xem xét thêm nữa.

Nếu bạn chỉ muốn một hướng dẫn trực quan, đơn giản để giúp bạn đo SOAP và REST theo yêu cầu ứng dụng của bạn ...

Vijay Prasad Gupta đã đưa ra một biểu đồ dòng chảy đơn giản, hữu ích.

Liên kết trực tiếp đến biểu đồ luồng: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

Liên kết đến bài viết: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-service-protatio-for-your-need

Bây giờ là năm 2015. Tôi đã hy vọng rằng SOAP đã chết cho đến bây giờ, nhưng nó vẫn còn lưu lại như một mùi hôi. Đối với bất cứ điều gì ngoại trừ các ứng dụng "ví dụ" cơ bản nhất, việc tích hợp với dịch vụ SOAP là rất khó khăn. Đó là một kiến ​​trúc phức tạp, với nhiều tùy chọn ở nhiều cấp độ, kết hợp với sự kỳ quặc của nhiều triển khai và sự không tương thích tinh tế (và không quá tinh tế). Tôi chưa bao giờ có một trải nghiệm tốt với nó. REST, mặt khác, rất dễ hiểu: mọi người đều hiểu HTTP. Trong hầu hết các trường hợp, JSON có nhiều tiện ích hơn so với XML Info set.

Để cho bạn biết về sự phức tạp của SOAP, hãy thử tích hợp thư viện SOAP vào dự án của bạn. Đối với Java, máy khách Apache Axis2 cơ bản nhất (sử dụng liên kết dữ liệu ADB đơn giản) kéo theo 23 JAR mới. Hai mươi ba! 20MB thư viện phình to. CXF tương tự: 21 JAR, khi tôi đếm lần cuối.

Nếu bạn thực sự muốn, bạn có thể thực hiện REST với thư viện HTTP đơn giản.