SOAP được phát minh để làm gì?

Câu hỏi này được lấy cảm hứng từ cái này . Mục tiêu ban đầu của việc phát minh ra SOAP là gì? Tại sao nó được phát minh khi chúng ta có HTTP và REST loại cũ?

REST không phải là một tiêu chuẩn, nó là một kiến ​​trúc (được xác định một cách lỏng lẻo). Và nó được gắn với HTTP, điều mà rất nhiều người trong thế giới doanh nghiệp coi là một hạn chế. Vì vậy, họ nghĩ rằng họ cần một tiêu chuẩn chung phù hợp, cũng hoạt động trên các lớp chuyển khác.

Và btw SOAP đã được xác định trước REST (ít nhất là theo Wikipedia :-)

SOAP là cách phù hợp hơn HTTP đơn giản để trao đổi các cấu trúc dữ liệu phức tạp. REST thực tế được thiết kế giới hạn trong các hoạt động CRUD, trong khi SOAP cho phép các cuộc gọi phương thức tùy ý, có thể là điều không thể được nhấn vào sơ đồ REST.

Từ Wikipedia :

SOAP, ban đầu được định nghĩa là Giao thức truy cập đối tượng đơn giản, là một đặc tả giao thức để trao đổi thông tin có cấu trúc trong việc triển khai Dịch vụ web trong mạng máy tính. ... SOAP có ba đặc điểm chính: Khả năng mở rộng (bảo mật và định tuyến WS nằm trong số các phần mở rộng đang được phát triển), Tính trung lập (SOAP có thể được sử dụng trên bất kỳ giao thức vận chuyển nào như HTTP, SMTP hoặc thậm chí TCP) và Độc lập (SOAP cho phép bất kỳ mô hình lập trình nào).

SOAP không giới hạn ở HTTP và cung cấp bảo mật ngay lập tức.

Nếu bạn đang sử dụng HTTP và bạn không cần bảo mật (dịch vụ web của bạn mở cho công chúng), thì bạn không cần SOAP.

Tôi không ở trong phòng, nhưng tôi thường nói rằng SOAP là một ý tưởng rất, rất hay và là một phản ứng rất hợp lý cho các tùy chọn RPC khác tồn tại từ giữa đến cuối những năm 90. Chẳng hạn như CORBA , một con thú mà tôi không thể nói rằng tôi phải đối phó với cá nhân, nhưng việc đề cập đến chỉ có thể khiến những người đàn ông trưởng thành trở thành đất. Các tùy chọn ngoài CORBA thực sự đáng sợ hơn trong nhiều trường hợp và có rất ít tiêu chuẩn hóa và rất nhiều giao thức nhắn tin tùy chỉnh đang diễn ra. Các hệ thống tích hợp là những thứ rất, rất cứng. Có những lý do chính đáng để không dựa vào HTTP như một phương tiện giao thông. Vào cuối những năm 90, tốc độ mạng LAN thông thường là 10 megabit hoặc ít hơn, tốc độ mạng LAN thường được đo bằng baud. Toàn bộ cơ sở hạ tầng bộ nhớ đệm cạnh rất nhiều cho REST không tồn tại.

Điều này đưa chúng ta đến SOAP - trong đó không chỉ định phương tiện vận chuyển. Tôi tin rằng ai đó đã quản lý để thực hiện một cuộc gọi SOAP trên chim bồ câu. Hoặc có lẽ là một con én châu Phi. Trong mọi trường hợp, việc triển khai tùy chọn nhắn tin đơn giản hơn nhiều so với trước đây. Và nếu bạn có một bộ công cụ SOAP phong nha, nó sẽ dễ tiêu thụ hơn nhiều so với bất kỳ thứ gì khác có trước đây. Và dễ dàng hơn để làm công cụ cho. Dễ dàng đến mức họ nghĩ rằng họ cần phải mở rộng giao thức. Và đó là nơi WS- * đến. Đó là nơi các bánh xe rơi ra khỏi chiếc xe tải đó. . .

SOAP là một giao thức nhắn tin, được tạo ra với cùng lý do bất kỳ giao thức nhắn tin nào khác đã được tạo ra; để chuẩn hóa cách thức mà thông tin đối tượng được truyền qua. Như trang Wikipedia nêu, nó có nguồn gốc từ Microsoft và hiện là một tiêu chuẩn mở được duy trì bởi W3C.

Câu hỏi tốt hơn là tại sao phải chọn giữa SOAP hoặc một số lược đồ có hương vị XML hoặc JSON hoặc bất cứ điều gì, và câu trả lời được đưa ra để sử dụng bất cứ điều gì dễ dàng / thực tế nhất trong tình huống cụ thể của bạn.

Theo ý kiến ​​của tôi, SOAP là một bước tiến khác tại RPC . Chỉ cần xem làm thế nào để bạn tiếp xúc với WebService những ngày này. Một bên đánh dấu phương thức là WebService và bên kia chỉ tìm nạp WSDL và sử dụng các phương thức từ xa như thể chúng là cục bộ. Tôi khá nhận thức được tất cả các vấn đề SOAP, nhưng ở một mức độ trừu tượng nào đó, SOAP / WS mang đến lời hứa RPC của nó. Tất nhiên bạn có thể đưa ra một API dựa trên kiến ​​trúc REST, nhưng nó vẫn sẽ yêu cầu bên khác mã hóa một số bit mà bằng cách nào đó bất chấp định nghĩa RPC.