Ưu và nhược điểm của kiến ​​trúc RESTful [đã đóng]

Cuộc thảo luận phổ biến nhất mà tôi đã thấy liên quan đến ưu và nhược điểm của REST có xu hướng đóng khung cuộc thảo luận đó liên quan đến SOAP. Tôi không có kinh nghiệm trong một trong hai. Tôi hiện đang phải đối mặt với một quyết định mà sự thiếu kinh nghiệm của tôi đang làm cho tôi khó đánh giá. Tôi đang bắt đầu phát triển một ứng dụng có một số thành phần - chủ yếu là khía cạnh quản trị cho phép chủ sở hữu quản trị một số trang - và giao diện người dùng phải đối mặt công khai cho phép người dùng tương tác với dữ liệu được lưu trữ trên máy chủ. Tôi cần đánh giá ý nghĩa của việc cho phép phần sau được lưu trữ ở bất cứ đâu và liên lạc với phần trước thông qua kiến ​​trúc RESTful - hoặc yêu cầu cả hai thành phần cư trú trên cùng một máy chủ. Ý nghĩa chính của việc phát triển kiến ​​trúc RESTful, đặc biệt là liên quan đến năng lực của nó trong các lĩnh vực sau:

1: Bảo mật 2: Hiệu suất 3: Độ phức tạp của giao diện

EDIT: Nhìn vào một số câu trả lời cho câu hỏi này - tôi nên làm rõ. Tôi không tìm kiếm sự so sánh với SOAP - thay vào đó là tổng quan về các ứng dụng REST so với các ứng dụng có tất cả các thành phần nằm trên một máy chủ. (cảm ơn vì những câu trả lời đó!)

Với những lĩnh vực đó, tôi có thể đưa ra một cái nhìn tổng quan, nhưng tôi không thể đưa ra kết luận của bạn cho bạn. Có hai lĩnh vực chính mà hai giao thức khác nhau:

• Định dạng tin nhắn
• Khám phá dịch vụ

Định dạng tin nhắn là dễ hiểu nhất. Bao bì SOAP cho cả yêu cầu và phản hồi có trọng lượng khá nặng. Có phong bì SOAP chứa cả phần tiêu đề và phần thân. Tiêu đề có thể được sử dụng bởi một số bộ lọc trong chuỗi yêu cầu để thực hiện một số loại nhận dạng, ủy quyền, v.v. Tuy nhiên, XML rất tốn kém để phân tích, điều này mang lại một hình phạt nhất định đối với khả năng mở rộng của hệ thống của bạn. Bao nhiêu tùy thuộc vào lớp xử lý SOAP trong ngăn xếp của bạn.

Khám phá dịch vụ là nơi bạn có thể sẽ có sự tranh chấp nhất. REST về bản chất cung cấp các điểm cuối có thể dự đoán được và nội dung của yêu cầu là một yêu cầu HTTP đơn giản. Lợi ích là không có chi phí bổ sung và người dùng cuối có thể đoán được cách thực hiện những gì họ cần một khi họ hiểu cấu trúc URL của trang web của bạn. Tất nhiên, những người có ý thức bảo mật ngây thơ sẽ coi đó là một điểm yếu. Sau tất cả, với SOAP, bạn phải sử dụng WSDL để biết điểm cuối là gì. Tất nhiên, với SOAP, bạn đã được cung cấp toàn bộ định dạng thư để bạn có thể thực hiện các cuộc tấn công được nhắm mục tiêu nhiều hơn.

Được chia nhỏ theo danh mục bạn đã đưa ra:

Bảo vệ

Không phải là vốn đã an toàn hơn so với khác. Sử dụng các nguyên tắc bảo mật tốt:

• Mã hóa thông tin liên lạc
• Đảm bảo bạn xác thực và ủy quyền cho người dùng trước khi xử lý
• Thói quen mã hóa tốt để tránh các cuộc tấn công trực tiếp
• Và đó chỉ là danh sách ngắn.

Nhớ tối nghĩa! = Bảo ​​mật.

Hiệu suất

Cả hiệu năng thô và khả năng mở rộng sẽ chuyển đến REST do yêu cầu theo các giao thức HTTP đơn giản. Hầu hết các ngăn xếp SOAP sử dụng phân tích SAX (phân tích dựa trên sự kiện) giúp cải thiện đáng kể khả năng mở rộng của các ngăn xếp SOAP, nhưng có tác động có thể đo lường được đối với chi phí chung. SOAP có chi phí xử lý HTTP bình thường bên cạnh chi phí phân tích cú pháp XML. REST chỉ có chi phí xử lý HTTP.

Phức tạp

Từ quan điểm của hệ thống, REST thắng. Có ít bộ phận chuyển động hơn, chuỗi yêu cầu gọn hơn, v.v. Điều đó có nghĩa là dễ dàng hơn để làm cho đáng tin cậy.

Từ quan điểm của lập trình viên, SOAP có thể giành chiến thắng nếu IDE hoặc khung bạn đang sử dụng cung cấp hỗ trợ tốt cho nó. Về cơ bản, với REST, trách nhiệm của bạn là thực hiện công việc tiền xử lý (xác thực / ủy quyền / v.v.) trong khi với SOAP, phần lớn có thể được thực hiện bằng chuỗi xử lý có thể cắm được.

Quyền của tôi

Tôi rất thoải mái với các yêu cầu HTTP và tôi biết web hoạt động như thế nào. Kết quả là, cách tiếp cận REST thích hợp hơn với tôi. Tuy nhiên, tôi biết rằng một số khách hàng của tôi không thoải mái với điều đó. Họ đã đọc một số bài báo trong ngành tố cáo tính bảo mật của REST so với SOAP, v.v. Điểm mấu chốt là không cách tiếp cận nào đảm bảo an ninh. Đó là vào bạn để đảm bảo ứng dụng được an toàn như nó cần phải có. Rõ ràng, một ứng dụng web xã hội không đòi hỏi (hoặc mong muốn) bảo mật nhiều như hệ thống ngân hàng hoặc chính phủ. Nhiều ngăn xếp SOAP bao gồm các bộ xử lý mà bạn có thể cắm vào để cung cấp một số lợi ích bảo mật, nhưng bạn vẫn có trách nhiệm tìm kiếm chúng và đặt chúng vào vị trí.

1. Bảo mật: Sử dụng HTTPS. Điều này áp dụng cho cả hai.
2. Hiệu suất : . REST ít tốn kém CPU hơn (ít phân tích cú pháp, sắp xếp theo thứ tự, bỏ ghép nối). Ngoài ra, bộ nhớ đệm với REST là một miếng bánh.
3. Độ phức tạp: REST yêu cầu ít hơn nhiều về mặt thiết lập, sau tất cả chỉ là NHẬN / POST. SOAP yêu cầu quản trị nhiều hơn để duy trì (wsdl, v.v.), nhưng sẽ dễ dàng hơn một chút nếu IDE của bạn hỗ trợ nó.

Tôi nghĩ SOAP quá phình to khi bạn có thể làm điều tương tự với REST và một số loại nội dung / mime. Ngoài ra, SOAP mang lại rất nhiều chi phí, do tính chất bao bọc của nó và thực tế là nó chung chung hơn và không giới hạn đối với HTTP. SOAP rất hấp dẫn để sử dụng nếu IDE của bạn hỗ trợ đúng cách và bạn không muốn học HTTP. Nhưng đối với tôi, REST dễ sử dụng hơn và thân thiện với web hơn nhiều.

Ngày nay, có các API REST rất tốt để sử dụng. Nếu bạn vào Java, thì Jax-RS thực sự rất tuyệt. Đối với một số người, điều này giống như khiêu dâm.

Tôi nghĩ lợi thế lớn nhất của REST là thoát khỏi các kiến ​​trúc RPC. REST trưng ra các tài nguyên, không phải các quy trình. Điều đó cho phép bạn tạo ra một hệ thống ràng buộc lỏng lẻo, trong đó những thay đổi, cải tiến, thậm chí là thất bại của một phần có tác động hạn chế (tiêu cực) đối với các phần khác.

Thật không may, một lạm dụng phổ biến của REST là làm lộ cấu trúc dữ liệu bên trong của bạn (trong trường hợp xấu nhất, đó là CRUD của cơ sở dữ liệu của bạn, ugh). Điều đó làm cho nó rất khó để làm điều đó một cách an toàn. Việc sử dụng 'quyền' là để lộ các đối tượng cấp cao có liên quan đến phần hệ thống bạn đang xử lý và tự do trả lại mã trạng thái lỗi trên bất kỳ sự không nhất quán nào.

Một phần khác thường bị bỏ qua của REST là tính không thay đổi của hầu hết các động từ. Không chỉ NHẬN, mà cả PUT và DELETE cũng phải chính xác như nhau nếu được áp dụng một lần hoặc nhiều lần (bạn sẽ không phải trả lại 404 nếu đã bị xóa hoặc 'không thay đổi' nếu ứng dụng khách PUTting giống nhau). Điều đó dẫn đến các hệ thống mạnh mẽ và ít phụ thuộc lẫn nhau vào các diễn giải chính xác về ngữ nghĩa.

Các tiêu chuẩn WS- * thực sự chủ yếu là về việc chạy RPC qua SOAP / HTTP. Vì vậy, tất cả những suy nghĩ đã đi vào CORBA và J2EE và những người tiền nhiệm của họ chủ yếu chuyển sang làm những việc tương tự trong XML. Điều này có nghĩa là những thứ như khai báo kiểu và hợp đồng dịch vụ, trao đổi siêu dữ liệu, bảo mật khai báo, v.v ... Tất cả những thứ thực sự "enterprisey". Nó được sử dụng quá mức ngay cả trong doanh nghiệp, thẳng thắn.

Những người xây dựng một ứng dụng web internet như bạn, gần như chắc chắn sẽ tốt hơn khi sử dụng kiến ​​trúc RESTful. Hầu như bất kỳ nền tảng nào cũng có thể sử dụng nó và làm như vậy một cách đơn giản và không phải lo lắng về phiên bản mà bạn đang sử dụng và vô số các quirks chuyển đổi loại công cụ cụ thể, v.v.

Chỉ có lợi thế lớn của SOAP so với các triển khai REST hiện tại là SOAP dễ sử dụng hơn - hầu hết các máy khách RESTful yêu cầu tôi hiểu giao diện và viết một ứng dụng khách nào đó. Đối với SOAP, tôi chỉ trỏ wsdl.exe vào nó và nó tạo các lớp cho tôi.