SOAP so với REST (sự khác biệt)

Tôi đã đọc các bài viết về sự khác biệt giữa SOAP và REST như một giao thức truyền thông dịch vụ web, nhưng tôi nghĩ rằng những lợi thế lớn nhất của REST so với SOAP là:

1. REST năng động hơn, không cần tạo và cập nhật UDDI (Mô tả chung, Khám phá và Tích hợp).

2. REST không bị hạn chế chỉ định dạng XML. Các dịch vụ web RESTful có thể gửi văn bản / JSON / XML đơn giản.

Nhưng SOAP được chuẩn hóa hơn (Ví dụ: bảo mật).

Vì vậy, tôi có đúng trong những điểm này?

Thật không may, có rất nhiều thông tin sai lệch và quan niệm sai lầm xung quanh REST. Không chỉ câu hỏi của bạn và câu trả lời của @cmd phản ánh những câu hỏi đó, mà hầu hết các câu hỏi và câu trả lời liên quan đến chủ đề trên Stack Overflow.

SOAP và REST không thể được so sánh trực tiếp, vì thứ nhất là một giao thức (hoặc ít nhất là cố gắng) và thứ hai là một kiểu kiến ​​trúc. Đây có lẽ là một trong những nguồn gây nhầm lẫn xung quanh nó, vì mọi người có xu hướng gọi REST bất kỳ API HTTP nào không phải là SOAP.

Đẩy mọi thứ lên một chút và cố gắng thiết lập một so sánh, sự khác biệt chính giữa SOAP và REST là mức độ khớp nối giữa các triển khai máy khách và máy chủ. Máy khách SOAP hoạt động giống như một ứng dụng máy tính để bàn tùy chỉnh, được liên kết chặt chẽ với máy chủ. Có một hợp đồng cứng nhắc giữa máy khách và máy chủ, và mọi thứ dự kiến ​​sẽ bị phá vỡ nếu một trong hai bên thay đổi bất cứ điều gì. Bạn cần cập nhật liên tục sau bất kỳ thay đổi nào, nhưng sẽ dễ dàng xác định hơn nếu hợp đồng được tuân theo.

Một máy khách REST giống như một trình duyệt. Đó là một máy khách chung biết cách sử dụng một giao thức và các phương thức được tiêu chuẩn hóa, và một ứng dụng phải phù hợp với điều đó. Bạn không vi phạm các tiêu chuẩn giao thức bằng cách tạo các phương thức bổ sung, bạn tận dụng các phương thức chuẩn và tạo các hành động với chúng trên loại phương tiện của mình. Nếu được thực hiện đúng, sẽ có ít khớp nối hơn và các thay đổi có thể được xử lý một cách duyên dáng hơn. Một khách hàng có nghĩa vụ nhập một dịch vụ REST không có kiến ​​thức về API, ngoại trừ điểm vào và loại phương tiện. Trong SOAP, khách hàng cần có kiến ​​thức trước đó về mọi thứ sẽ sử dụng hoặc thậm chí sẽ không bắt đầu tương tác. Ngoài ra, ứng dụng khách REST có thể được mở rộng bằng mã theo yêu cầu do chính máy chủ cung cấp,

Tôi nghĩ đây là những điểm cốt yếu để hiểu REST là gì và nó khác với SOAP như thế nào:

• REST là giao thức độc lập. Nó không được kết hợp với HTTP. Khá giống như bạn có thể theo liên kết ftp trên một trang web, một ứng dụng REST có thể sử dụng bất kỳ giao thức nào có sơ đồ URI được tiêu chuẩn hóa.

• REST không phải là ánh xạ của CRUD sang các phương thức HTTP. Đọc câu trả lời này để được giải thích chi tiết về điều đó.

• REST được chuẩn hóa như các phần bạn đang sử dụng. Bảo mật và xác thực trong HTTP được chuẩn hóa, vì vậy đó là những gì bạn sử dụng khi thực hiện REST qua HTTP.

• REST không phải là REST mà không có hypermedia và HATEOAS . Điều này có nghĩa là một khách hàng chỉ biết URI điểm vào và các tài nguyên được cho là trả về các liên kết mà khách hàng nên theo dõi. Các trình tạo tài liệu ưa thích cung cấp các mẫu URI cho mọi thứ bạn có thể làm trong API REST hoàn toàn bỏ lỡ điểm. Họ không chỉ ghi lại một cái gì đó được cho là tuân theo tiêu chuẩn, mà khi bạn làm điều đó, bạn sẽ ghép khách hàng với một thời điểm cụ thể trong quá trình phát triển API và mọi thay đổi trên API phải được ghi lại và áp dụng, hoặc nó sẽ vỡ

• REST là phong cách kiến ​​trúc của chính web. Khi bạn nhập Stack Overflow, bạn sẽ biết Người dùng, Câu hỏi và Câu trả lời là gì, bạn biết các loại phương tiện và trang web cung cấp cho bạn các liên kết đến chúng. Một API REST phải làm như vậy. Nếu chúng tôi thiết kế web theo cách mọi người nghĩ REST nên được thực hiện, thay vì có một trang chủ có liên kết đến Câu hỏi và Trả lời, chúng tôi sẽ có một tài liệu tĩnh giải thích rằng để xem câu hỏi, bạn phải lấy URI stackoverflow.com/questions/<id>, thay thế id bằng Câu hỏi và dán nó trên trình duyệt của bạn. Điều đó thật vô lý, nhưng đó là điều mà nhiều người nghĩ REST là.

Điểm cuối cùng này không thể được nhấn mạnh đủ. Nếu khách hàng của bạn đang xây dựng URI từ các mẫu trong tài liệu và không nhận được liên kết trong các biểu diễn tài nguyên, thì đó không phải là REST. Roy Fielding, tác giả của REST, đã nói rõ trên bài đăng trên blog này: API REST phải được điều khiển siêu văn bản .

Với ý nghĩ trên, bạn sẽ nhận ra rằng mặc dù REST có thể không bị hạn chế đối với XML, nhưng để thực hiện chính xác với bất kỳ định dạng nào khác, bạn sẽ phải thiết kế và chuẩn hóa một số định dạng cho các liên kết của mình. Các siêu liên kết là tiêu chuẩn trong XML, nhưng không phải trong JSON. Có các tiêu chuẩn dự thảo cho JSON, như HAL .

Cuối cùng, REST không dành cho tất cả mọi người và một bằng chứng cho thấy đó là cách mà hầu hết mọi người giải quyết vấn đề của họ rất tốt với các API HTTP mà họ gọi nhầm là REST và không bao giờ mạo hiểm vượt quá điều đó. Đôi khi REST khó thực hiện, đặc biệt là vào lúc đầu, nhưng nó trả tiền theo thời gian với sự tiến hóa dễ dàng hơn ở phía máy chủ và khả năng phục hồi của khách hàng đối với các thay đổi. Nếu bạn cần một cái gì đó được thực hiện nhanh chóng và dễ dàng, đừng bận tâm về việc làm cho REST đúng. Nó có thể không phải là những gì bạn đang tìm kiếm. Nếu bạn cần một cái gì đó sẽ phải trực tuyến trong nhiều năm hoặc thậm chí nhiều thập kỷ, thì REST là dành cho bạn.

RESTvs SOAPlà không vấn đề quyền yêu cầu.

REST, Không giống như SOAPlà không một giao thức.

RESTlà một phong cách kiến ​​trúc và một thiết kế cho các kiến ​​trúc phần mềm dựa trên mạng.

RESTkhái niệm được gọi là tài nguyên. Một đại diện của một tài nguyên phải được không quốc tịch. Nó được thể hiện thông qua một số loại phương tiện truyền thông. Một số ví dụ về các loại phương tiện truyền thông bao gồm XML, JSONvà RDF. Tài nguyên được thao tác bởi các thành phần. Các thành phần yêu cầu và thao tác tài nguyên thông qua một giao diện thống nhất tiêu chuẩn. Trong trường hợp của HTTP, giao diện này bao gồm ops HTTP chuẩn ví dụ như GET, PUT, POST, DELETE.

Câu hỏi của @ Abdulaziz làm sáng tỏ thực tế đó RESTvà HTTPthường được sử dụng song song. Điều này chủ yếu là do sự đơn giản của HTTP và ánh xạ rất tự nhiên của nó theo các nguyên tắc RESTful.

Nguyên tắc REST cơ bản

Giao tiếp giữa máy khách và máy chủ

Kiến trúc máy khách-máy chủ có một mối quan tâm rất riêng biệt. Tất cả các ứng dụng được xây dựng theo kiểu RESTful về nguyên tắc cũng phải là máy khách-máy chủ.

Không quốc tịch

Mỗi yêu cầu máy khách đến máy chủ yêu cầu trạng thái của nó được thể hiện đầy đủ. Máy chủ phải có thể hiểu hoàn toàn yêu cầu của máy khách mà không cần sử dụng bất kỳ bối cảnh máy chủ hoặc trạng thái phiên máy chủ nào. Nó theo sau rằng tất cả các trạng thái phải được giữ trên máy khách.

Bộ nhớ cache

Các ràng buộc bộ đệm có thể được sử dụng, do đó cho phép dữ liệu phản hồi được đánh dấu là có thể lưu trong bộ nhớ cache hoặc không lưu trong bộ nhớ cache. Bất kỳ dữ liệu nào được đánh dấu là có thể lưu trong bộ nhớ cache có thể được sử dụng lại làm phản hồi cho cùng một yêu cầu tiếp theo.

Giao diện thống nhất

Tất cả các thành phần phải tương tác thông qua một giao diện thống nhất duy nhất. Bởi vì tất cả các tương tác thành phần xảy ra thông qua giao diện này, tương tác với các dịch vụ khác nhau rất đơn giản. Giao diện giống nhau! Điều này cũng có nghĩa là những thay đổi thực hiện có thể được thực hiện một cách cô lập. Những thay đổi như vậy, sẽ không ảnh hưởng đến tương tác thành phần cơ bản vì giao diện thống nhất luôn không thay đổi. Một nhược điểm là bạn bị kẹt với giao diện. Nếu tối ưu hóa có thể được cung cấp cho một dịch vụ cụ thể bằng cách thay đổi giao diện, bạn sẽ không gặp may vì REST cấm điều này. Tuy nhiên, về mặt sáng sủa, REST được tối ưu hóa cho web, do đó mức độ phổ biến đáng kinh ngạc của REST so với HTTP!

Các khái niệm trên thể hiện các đặc điểm xác định của REST và phân biệt kiến ​​trúc REST với các kiến ​​trúc khác như các dịch vụ web. Rất hữu ích khi lưu ý rằng dịch vụ REST là dịch vụ web, nhưng dịch vụ web không nhất thiết phải là dịch vụ REST.

Xem bài đăng trên blog này về Nguyên tắc thiết kế REST để biết thêm chi tiết về REST và các viên đạn đã nêu ở trên.

EDIT: cập nhật nội dung dựa trên ý kiến

Cả SOAP ( Giao thức truy cập đối tượng đơn giản ) và REST ( Chuyển trạng thái đại diện ) đều đẹp theo cách của chúng. Vì vậy, tôi không so sánh chúng. Thay vào đó, tôi đang cố gắng miêu tả bức tranh, khi tôi thích sử dụng REST và khi SOAP.

Tải trọng là gì?

Khi dữ liệu được gửi qua Internet, mỗi đơn vị được truyền bao gồm cả thông tin tiêu đề và dữ liệu thực tế được gửi. Tiêu đề xác định nguồn và đích của gói, trong khi dữ liệu thực tế được gọi là tải trọng . Nói chung, tải trọng là dữ liệu được mang thay mặt cho một ứng dụng và dữ liệu được nhận bởi hệ thống đích.

Bây giờ, ví dụ, tôi phải gửi một Telegram và tất cả chúng ta đều biết rằng chi phí của telegram sẽ phụ thuộc vào một số từ.

Vì vậy, hãy cho tôi biết trong số dưới đây đã đề cập đến hai tin nhắn này, cái nào rẻ hơn để gửi?

<name>Arin</name>

hoặc là

"name": "Arin"

Tôi biết câu trả lời của bạn sẽ là câu thứ hai mặc dù cả hai đại diện cho cùng một thông điệp thứ hai rẻ hơn về chi phí.

Vì vậy, tôi đang cố gắng nói rằng, gửi dữ liệu qua mạng ở định dạng JSON rẻ hơn so với gửi dữ liệu ở định dạng XML liên quan đến tải trọng .

Đây là lợi ích hoặc lợi thế đầu tiên của REST so với SOAP . SOAP chỉ hỗ trợ XML, nhưng REST hỗ trợ các định dạng khác nhau như văn bản, JSON, XML, v.v. Và chúng tôi đã biết, nếu chúng tôi sử dụng Json thì chắc chắn chúng tôi sẽ ở vị trí tốt hơn về tải trọng.

Bây giờ, SOAP hỗ trợ XML duy nhất, nhưng nó cũng có những ưu điểm của nó.

Có thật không! Làm sao?

SOAP dựa trên XML theo ba cách Phong bì - định nghĩa những gì trong thông báo và cách xử lý nó.

Một tập hợp các quy tắc mã hóa cho các loại dữ liệu và cuối cùng là cách bố trí các cuộc gọi và phản hồi thủ tục được thu thập.

Phong bì này được gửi qua một phương tiện giao thông (HTTP / HTTPS) và RPC (Cuộc gọi thủ tục từ xa) được thực thi và phong bì được trả về với thông tin trong tài liệu được định dạng XML.

Điểm quan trọng là một trong những lợi thế của SOAP là việc sử dụng phương thức vận chuyển chung chung của REST nhưng REST sử dụng HTTP / HTTPS . SOAP có thể sử dụng hầu hết mọi phương tiện vận chuyển để gửi yêu cầu nhưng REST không thể. Vì vậy, ở đây chúng tôi có một lợi thế của việc sử dụng SOAP.

Như tôi đã đề cập ở đoạn trên, REST REST sử dụng HTTP / HTTPS , vì vậy hãy đi sâu hơn một chút về những từ này.

Khi chúng ta đang nói về REST qua HTTP, tất cả các biện pháp bảo mật được áp dụng HTTP đều được kế thừa và điều này được gọi là bảo mật cấp độ vận chuyển và nó chỉ bảo mật các tin nhắn khi nó ở trong dây nhưng một khi bạn đã gửi nó ở phía bên kia thì bạn không biết nó sẽ phải trải qua bao nhiêu giai đoạn trước khi đạt đến điểm thực sự nơi dữ liệu sẽ được xử lý. Và tất nhiên, tất cả các giai đoạn đó có thể sử dụng một cái gì đó khác với HTTP. Vì vậy, nghỉ ngơi không an toàn hơn hoàn toàn, phải không?

Nhưng SOAP hỗ trợ SSL giống như REST, nó cũng hỗ trợ WS-Security , bổ sung một số tính năng bảo mật doanh nghiệp. WS-Security cung cấp bảo vệ khỏi việc tạo thông điệp đến mức tiêu thụ của nó . Vì vậy, đối với bảo mật cấp độ vận chuyển, bất kỳ kẽ hở nào chúng tôi thấy có thể được ngăn chặn bằng WS-Security.

Ngoài ra, do REST bị giới hạn bởi giao thức HTTP nên hỗ trợ giao dịch không tuân thủ ACID cũng như không thể cung cấp cam kết hai pha trên các tài nguyên xuyên quốc gia phân tán.

Nhưng SOAP có hỗ trợ toàn diện cho cả quản lý giao dịch dựa trên ACID cho các giao dịch ngắn hạn và quản lý giao dịch dựa trên bồi thường cho các giao dịch dài hạn. Nó cũng hỗ trợ cam kết hai pha trên các tài nguyên phân tán .

Tôi không rút ra bất kỳ kết luận nào, nhưng tôi sẽ thích dịch vụ web dựa trên SOAP trong khi bảo mật, giao dịch, v.v. là những mối quan tâm chính.

Dưới đây là "Hướng dẫn Java EE 6" nơi họ đã nói Thiết kế RESTful có thể phù hợp khi các điều kiện sau được đáp ứng . Có một cái nhìn.

Hy vọng bạn thích đọc câu trả lời của tôi.

REST ( RE trình bày S tate T ransfer)
RE trình bày S tate của một đối tượng là T ransferred là REST tức là chúng tôi không gửi Object, chúng tôi gửi trạng thái của Object. REST là một phong cách kiến ​​trúc. Nó không định nghĩa rất nhiều tiêu chuẩn như SOAP. REST là để hiển thị API công khai (ví dụ API Facebook, API Google Maps) qua internet để xử lý các hoạt động CRUD trên dữ liệu. REST tập trung vào việc truy cập các tài nguyên được đặt tên thông qua một giao diện nhất quán duy nhất.

SOAP ( S imple O bject A ccess P rotatio )
SOAP mang giao thức riêng của mình và tập trung vào việc phơi bày các phần logic ứng dụng (không phải dữ liệu) dưới dạng dịch vụ. SOAP trưng bày các hoạt động. SOAP tập trung vào việc truy cập các hoạt động được đặt tên, mỗi hoạt động thực hiện một số logic nghiệp vụ. Mặc dù SOAP thường được gọi là dịch vụ web nhưng đây là cách gọi sai. SOAP có rất ít nếu có bất cứ điều gì liên quan đến Web. REST cung cấp các dịch vụ Web thực sự dựa trên URI và HTTP.

Tại sao lại là REST?

• Vì REST sử dụng HTTP tiêu chuẩn, nó đơn giản hơn nhiều về mọi mặt.
• REST dễ thực hiện hơn, đòi hỏi ít băng thông và tài nguyên hơn.
• REST cho phép nhiều định dạng dữ liệu khác nhau trong đó SOAP chỉ cho phép XML.
• REST cho phép hỗ trợ tốt hơn cho các máy khách trình duyệt do hỗ trợ JSON của nó.
• REST có hiệu suất và khả năng mở rộng tốt hơn. Việc đọc REST có thể được lưu trữ, các lần đọc dựa trên SOAP không thể được lưu vào bộ nhớ cache.
• Nếu bảo mật không phải là mối quan tâm chính và chúng tôi có nguồn lực hạn chế. Hoặc chúng tôi muốn tạo một API dễ dàng được sử dụng công khai bởi các nhà phát triển khác thì chúng tôi nên sử dụng REST.
• Nếu chúng ta cần các hoạt động CRUD không trạng thái thì hãy đi với REST.
• REST thường được sử dụng trong phương tiện truyền thông xã hội, trò chuyện trên web, dịch vụ di động và API công cộng như Google Maps.
• Dịch vụ RESTful trả về nhiều MediaTypes khác nhau cho cùng một tài nguyên, tùy thuộc vào tham số tiêu đề yêu cầu "Chấp nhận" là application/xmlhoặc application/jsoncho POST và /user/1234.jsonhoặc GET /user/1234.xmlcho GET.
• Các dịch vụ REST có nghĩa là được gọi bởi ứng dụng phía máy khách chứ không phải người dùng cuối trực tiếp.
• ST trong REST xuất phát từ S tate T ransfer. Bạn chuyển trạng thái xung quanh thay vì để máy chủ lưu trữ nó, điều này làm cho các dịch vụ REST có thể mở rộng.

Tại sao lại là SOAP?

• SOAP không dễ thực hiện và đòi hỏi nhiều băng thông và tài nguyên hơn.
• Yêu cầu thông báo SOAP được xử lý chậm hơn so với REST và nó không sử dụng cơ chế lưu trữ web.
• WS-Security: Mặc dù SOAP hỗ trợ SSL (giống như REST), nó cũng hỗ trợ WS-Security có thêm một số tính năng bảo mật doanh nghiệp.
• WS-AtomicTransaction: Cần giao dịch ACID trên một dịch vụ, bạn sẽ cần SOAP.
• WS-TrustedMessaging: Nếu ứng dụng của bạn cần xử lý không đồng bộ và mức độ tin cậy và bảo mật được đảm bảo. Phần còn lại không có hệ thống nhắn tin tiêu chuẩn và mong muốn khách hàng xử lý các lỗi giao tiếp bằng cách thử lại.
• Nếu bảo mật là mối quan tâm chính và tài nguyên không bị giới hạn thì chúng ta nên sử dụng các dịch vụ web SOAP. Giống như nếu chúng ta đang tạo một dịch vụ web cho các cổng thanh toán, các công việc liên quan đến tài chính và viễn thông thì chúng ta nên sử dụng SOAP vì ở đây cần bảo mật cao.

nguồn1
nguồn2

Sự khác biệt giữa Nghỉ ngơi và Xà phòng

XÀ BÔNG

1. SOAP là một giao thức.
2. SOAP là viết tắt của Giao thức truy cập đối tượng đơn giản.
3. SOAP không thể sử dụng REST vì nó là một giao thức.
4. SOAP sử dụng các giao diện dịch vụ để thể hiện logic kinh doanh.
5. SOAP xác định các tiêu chuẩn phải được tuân thủ nghiêm ngặt.
6. SOAP yêu cầu nhiều băng thông và tài nguyên hơn REST.
7. SOAP xác định bảo mật của riêng mình.
8. SOAP chỉ cho phép định dạng dữ liệu XML.
9. SOAP ít được ưu tiên hơn REST.

NGHỈ NGƠI

1. REST là một phong cách kiến ​​trúc.
2. REST là viết tắt của Chuyển giao Nhà nước Đại diện.
3. REST có thể sử dụng các dịch vụ web SOAP vì đây là một khái niệm và có thể sử dụng bất kỳ giao thức nào như HTTP, SOAP.
4. REST sử dụng URI để hiển thị logic nghiệp vụ.
5. REST không định nghĩa quá nhiều tiêu chuẩn như SOAP.
6. REST yêu cầu ít băng thông và tài nguyên hơn SOAP.
7. Các dịch vụ web RESTful kế thừa các biện pháp bảo mật từ việc vận chuyển cơ bản.
8. REST cho phép định dạng dữ liệu khác nhau như Văn bản thuần túy, HTML, XML, JSON, v.v.
9. REST được ưu tiên hơn SOAP.

Để biết thêm chi tiết xin vui lòng xem tại đây

IMHO bạn không thể so sánh SOAP và REST trong đó có hai thứ khác nhau.

SOAP là một giao thức và REST là một mẫu kiến ​​trúc phần mềm. Có rất nhiều quan niệm sai lầm trên internet về SOAP vs REST .

SOAP định nghĩa định dạng thông báo dựa trên XML mà các ứng dụng hỗ trợ dịch vụ web sử dụng để liên lạc với nhau qua internet. Để làm được điều đó, các ứng dụng cần có kiến ​​thức trước về hợp đồng tin nhắn, kiểu dữ liệu, v.v.

REST đại diện cho trạng thái (dưới dạng tài nguyên) của máy chủ từ một URL. Nó không trạng thái và khách hàng không nên có kiến ​​thức trước để tương tác với máy chủ ngoài sự hiểu biết về hypermedia.

Trước hết: chính thức, câu hỏi đúng sẽ là web services + WSDL + SOAPvs REST.

Bởi vì, mặc dù dịch vụ web , được sử dụng theo nghĩa lỏng lẻo, khi sử dụng giao thức HTTP để truyền dữ liệu thay vì các trang web, chính thức nó là một hình thức rất cụ thể của ý tưởng đó. Theo định nghĩa, REST không phải là "dịch vụ web".

Tuy nhiên, trên thực tế, mọi người đều bỏ qua điều đó, vì vậy chúng ta cũng bỏ qua nó

Đã có câu trả lời kỹ thuật, vì vậy tôi sẽ cố gắng cung cấp một số trực giác.

Giả sử bạn muốn gọi một chức năng trong một máy tính từ xa, được triển khai bằng một số ngôn ngữ lập trình khác (điều này thường được gọi là cuộc gọi thủ tục từ xa / RPC ). Giả sử rằng chức năng có thể được tìm thấy tại một URL cụ thể, được cung cấp bởi người đã viết nó. Bạn phải (bằng cách nào đó) gửi tin nhắn và nhận được phản hồi. Vì vậy, có hai câu hỏi chính để xem xét.

• định dạng của tin nhắn bạn nên gửi là gì
• tin nhắn nên được chuyển qua lại như thế nào

Đối với câu hỏi đầu tiên, định nghĩa chính thức là WSDL . Đây là một tệp XML mô tả, ở định dạng chi tiết và nghiêm ngặt, các tham số là gì, loại, tên, giá trị mặc định, tên của hàm được gọi, v.v. Ví dụ WSDL ở đây cho thấy tệp đó là con người -đọc được (nhưng không dễ).

Đối với câu hỏi thứ hai, có nhiều câu trả lời khác nhau. Tuy nhiên, thứ duy nhất được sử dụng trong thực tế là SOAP . Ý tưởng chính của nó là: bọc XML trước đó (thông điệp thực tế) vào một XML khác (chứa thông tin mã hóa và các nội dung hữu ích khác) và gửi nó qua HTTP. Phương thức POST của HTTP được sử dụng để gửi tin nhắn, vì luôn có một phần thân .

Ý tưởng chính của toàn bộ cách tiếp cận này là bạn ánh xạ URL tới một hàm , nghĩa là thành một hành động . Vì vậy, nếu bạn có một danh sách khách hàng trong một số máy chủ và bạn muốn xem / cập nhật / xóa một, bạn phải có 3 URL:

• myapp/read-customer và trong phần thân của tin nhắn, hãy chuyển id của khách hàng để đọc.
• myapp/update-customer và trong cơ thể, vượt qua id của khách hàng, cũng như dữ liệu mới
• myapp/delete-customer và id trong cơ thể

Cách tiếp cận REST thấy mọi thứ khác nhau. Một URL không nên đại diện cho một hành động, mà là một thứ (được gọi là tài nguyên trong biệt ngữ REST). Vì giao thức HTTP (mà chúng tôi đang sử dụng) hỗ trợ các động từ, hãy sử dụng các động từ đó để chỉ định những hành động cần thực hiện đối với sự việc.

Vì vậy, với phương pháp REST, khách hàng số 12 sẽ được tìm thấy trên URL myapp/customers/12. Để xem dữ liệu khách hàng, bạn nhấn URL với yêu cầu NHẬN. Để xóa nó, cùng một URL, với một động từ XÓA. Để cập nhật nó, một lần nữa, cùng một URL với động từ POST và nội dung mới trong phần thân yêu cầu.

Để biết thêm chi tiết về các yêu cầu mà một dịch vụ phải đáp ứng để được coi là RESTful thực sự, hãy xem mô hình trưởng thành của Richardson . Bài viết đưa ra các ví dụ và quan trọng hơn là giải thích tại sao dịch vụ SOAP (được gọi là), là dịch vụ REST cấp 0 (mặc dù, cấp 0 có nghĩa là tuân thủ thấp đối với mô hình này, nó không gây khó chịu và vẫn hữu ích trong nhiều trường hợp).

Trong số nhiều câu trả lời khác đã được nêu trong nhiều câu trả lời, tôi nhấn mạnh rằng SOAP cho phép xác định hợp đồng, WSDL, định nghĩa các hoạt động được hỗ trợ, các loại phức tạp, v.v. SOAP được định hướng cho các hoạt động, nhưng REST hướng vào các tài nguyên. Cá nhân tôi sẽ chọn SOAP cho các giao diện phức tạp giữa các ứng dụng doanh nghiệp nội bộ và REST cho các giao diện công khai, đơn giản hơn, không trạng thái với thế giới bên ngoài.

Bổ sung cho:

++ Một lỗi thường xảy ra khi tiếp cận REST là nghĩ về nó như các dịch vụ web của URL với URL. Không gian tên XML.

++ Ngược lại, REST không liên quan nhiều đến RPC. Trong khi RPC được định hướng dịch vụ và tập trung vào các hành động và động từ, REST là định hướng tài nguyên, nhấn mạnh những điều và danh từ bao gồm một ứng dụng.

Rất nhiều câu trả lời hoàn toàn quên đề cập đến các điều khiển hypermedia (HATEOAS) hoàn toàn cơ bản đối với REST. Một vài người khác đã chạm vào nó, nhưng không thực sự giải thích nó tốt như vậy.

Bài viết này sẽ giải thích sự khác biệt giữa các khái niệm, mà không đi sâu vào cỏ dại trên các tính năng SOAP cụ thể.