Tại sao chúng ta cần Dịch vụ Web RESTful?

Tôi sẽ học các dịch vụ web RESTful (tốt hơn là nói rằng tôi sẽ phải làm điều này vì đây là một phần của chương trình cấp bằng thạc sĩ CS).

Tôi đã đọc một số thông tin trên Wikipedia và tôi cũng đã đọc một bài viết về REST tại Sun Developer Network và tôi thấy rằng đó không phải là công nghệ dễ dàng, có các khung đặc biệt để xây dựng các ứng dụng RESTful và nó thường được so sánh với các dịch vụ web SOAP và lập trình viên nên hiểu khi nào nên sử dụng SOAP và khi nào REST có thể là phương pháp hay.

Tôi nhớ rằng vài năm trước SOAP rất phổ biến (thời trang?) Và mục 'SOAP' phải có mặt trong mỗi CV tốt. Nhưng trong thực tế, nó được sử dụng rất hiếm khi và để đạt được những mục đích rất đơn giản.

Dường như với tôi rằng REST là một 'từ cuối cùng của thời trang' (hoặc tôi có thể hoàn toàn sai vì tôi chưa bao giờ thấy REST trong thực tế).

Bạn có thể cho tôi một số ví dụ là REST nên được sử dụng và tại sao chúng ta không thể làm tương tự mà không có REST (hoặc tại sao chúng ta nên dành nhiều thời gian hơn để làm điều tương tự mà không cần REST)?

CẬP NHẬT : Không may mắn Tôi không thể thấy bất kỳ đối số cụ thể nào có thể thổi vào tâm trí của tôi trong những bình luận đầu tiên. Làm tôi nghĩ rằng REST là công nghệ tuyệt vời!

Tôi muốn xem câu trả lời như thế này:

Tôi đang phát triển một ứng dụng HelloWorld phức tạp khác và chúng tôi cần chuyển nhiều dữ liệu / dữ liệu nhỏ và tôi đã đề xuất giải pháp REST cho đồng nghiệp của mình:

- Chết tiệt! Jonny, chúng tôi chắc chắn nên sử dụng REST để thực hiện ứng dụng này!
- Vâng, Billy, chúng tôi có thể sử dụng REST, nhưng chúng tôi sẽ sử dụng SOAP tốt hơn. Hãy tin tôi đi vì tôi biết vài điều về việc phát triển ứng dụng HelloWorld.
- Nhưng SOAP là công nghệ lỗi thời từ thế kỷ trước và chúng ta có thể sử dụng công nghệ tốt hơn.
- Billy, bạn đã sẵn sàng dành 3 ngày để thử nghiệm với REST chưa? Chúng tôi có thể làm điều này với SOAP trong 2 giờ ..
- Vâng, tôi chắc chắn rằng chúng tôi sẽ dành nhiều thời gian hơn để đạt được cùng mức bảo mật / hiệu suất / / khả năng mở rộng / bất cứ điều gì khác với SOAP. Tôi chắc chắn rằng các ứng dụng HelloWorld chỉ nên được phát triển với REST.

REST nên được sử dụng nếu nó rất quan trọng đối với bạn để giảm thiểu khớp nối giữa các thành phần máy khách và máy chủ trong một ứng dụng phân tán.

Đây có thể là trường hợp nếu máy chủ của bạn sẽ được sử dụng bởi nhiều khách hàng khác nhau mà bạn không có quyền kiểm soát. Nó cũng có thể là trường hợp nếu bạn muốn có thể cập nhật máy chủ thường xuyên mà không cần cập nhật phần mềm máy khách.

Tôi có thể đảm bảo với bạn rằng việc đạt được mức độ ghép thấp này là không dễ thực hiện . Điều quan trọng là phải tuân theo tất cả các ràng buộc của REST để thành công. Duy trì một kết nối hoàn toàn không trạng thái là khó khăn. Chọn đúng loại phương tiện và ép dữ liệu của bạn vào các định dạng là khó khăn. Tạo các loại phương tiện truyền thông của riêng bạn có thể còn khó hơn.

Việc điều chỉnh hành vi máy chủ phong phú vào giao diện HTTP thống nhất có thể gây nhầm lẫn và đôi khi xuất hiện phạm vi so với phương pháp RPC tương đối đơn giản.

Mặc dù có những khó khăn, nhưng lợi ích là bạn có một dịch vụ mà nhà phát triển khách hàng có thể dễ dàng hiểu được do việc sử dụng giao thức HTTP nhất quán. Dịch vụ này có thể dễ dàng khám phá do hypermedia và máy khách phải cực kỳ linh hoạt với các thay đổi trên máy chủ .

Những lợi ích của hypermedia và tránh trạng thái phiên làm cho việc cân bằng tải trở nên đơn giản và phân vùng dịch vụ là khả thi . Sự tuân thủ nghiêm ngặt các quy tắc HTTP làm cho sự sẵn có của các công cụ như trình gỡ lỗi và proxy lưu trữ là điều tuyệt vời.

Cập nhật

Dường như với tôi rằng REST là một 'từ cuối cùng của thời trang' (hoặc tôi có thể hoàn toàn sai vì tôi chưa bao giờ thấy REST trong thực tế).

Tôi nghĩ rằng REST đã trở thành mốt bởi vì mọi người khi cố gắng thực hiện các dự án kiểu SOA đã phát hiện ra rằng sử dụng ngăn xếp SOAP họ không nhận ra những lợi ích đã được hứa hẹn. Mọi người tiếp tục quay lại web như một ví dụ về các phương pháp tích hợp đơn giản. Thật không may, tôi nghĩ mọi người đánh giá thấp số lượng kế hoạch và tầm nhìn xa đã tạo ra web và họ áp dụng quá mức những gì cần phải làm để cho phép loại tái sử dụng tình cờ xảy ra trên web.

Bạn nói rằng bạn chưa bao giờ thấy REST trong thực tế, nhưng điều đó không thể đúng nếu bạn từng sử dụng trình duyệt web. Trình duyệt web là một ứng dụng khách REST.

• Tại sao bạn không cần cập nhật trình duyệt khi ai đó thay đổi một số html trên trang web?
• Tại sao tôi có thể thêm một bộ trang hoàn chỉnh mới vào một trang web và "khách hàng" vẫn có thể truy cập các trang mới đó mà không cần cập nhật?
• Tại sao tôi không cần cung cấp "ngôn ngữ mô tả dịch vụ" cho trình duyệt web để thông báo cho nó khi truy cập http://example.org/images/cat rằng loại trả về sẽ là hình ảnh jpeg và khi bạn đi đến http://example.org/description/cat loại trả về sẽ là văn bản / html?
• Tại sao tôi có thể sử dụng trình duyệt web để truy cập các trang web không tồn tại khi trình duyệt được phát hành? Làm thế nào khách hàng có thể biết về các trang web này?

Những câu hỏi này nghe có vẻ giống như những câu hỏi vô ích, nhưng nếu bạn biết câu trả lời, thì bạn có thể bắt đầu xem REST là gì. Nhìn vào StackOverflow để biết thêm lợi ích của REST. Khi tôi đang xem một câu hỏi, tôi có thể đánh dấu trang đó hoặc gửi url cho một người bạn và anh ta có thể xem thông tin tương tự. Anh ta không phải điều hướng qua trang web để tìm câu hỏi đó.

StackOverflow sử dụng nhiều dịch vụ OpenId để xác thực, gravatar.com cho hình ảnh đại diện, phân tích google và Quantserve cho thông tin phân tích. Kiểu tích hợp đa công ty này là kiểu thế giới SOAP chỉ mơ ước . Một trong những ví dụ tốt nhất là thực tế là các thư viện jQuery được sử dụng để điều khiển UI StackOverflow được lấy từ Mạng phân phối nội dung của Google. Việc SO có thể hướng khách hàng (tức là trình duyệt web của bạn) tải xuống mã từ trang web của bên thứ ba để cải thiện hiệu suất là minh chứng cho sự kết hợp thấp giữa máy khách web và máy chủ.

Đây là những ví dụ về kiến ​​trúc REST tại nơi làm việc.

Bây giờ một số trang web / ứng dụng phá vỡ các quy tắc của REST và sau đó trình duyệt không hoạt động như mong đợi.

• Vấn đề nút quay lại khét tiếng là do sử dụng trạng thái phiên phía máy chủ.
• Cân bằng tải có thể trở thành một nỗi đau khi bạn có trạng thái phiên phía máy chủ.
• Các ứng dụng flash thường ngăn URL xác định cụ thể một đại diện.
• Vấn đề khác làm hỏng trình duyệt web là sự tuân thủ kém đối với các tiêu chuẩn loại phương tiện truyền thông. Chúng tôi nghe tất cả thời gian về cách IE6 cần phải bị giết. Vấn đề ở đây là các tiêu chuẩn không được tuân thủ đúng, hoặc bị bỏ qua vì bất kỳ lý do gì.
• Việc sử dụng các phiên đăng nhập là nguồn gốc của nhiều lỗ hổng bảo mật.

REST ở khắp mọi nơi. Nó là một phần của web làm cho nó hoạt động tốt. Nếu bạn muốn xây dựng các ứng dụng phân tán có thể mở rộng như web, hãy kiên cường thay đổi như web và thúc đẩy sử dụng lại như web đã làm, sau đó làm theo các quy tắc tương tự họ đã làm khi xây dựng trình duyệt web.

Theo hiểu biết của tôi, REST đã được khởi động bởi luận văn Phong cách kiến ​​trúc của Roy Fielding và Thiết kế Kiến trúc phần mềm dựa trên mạng , đáng để đọc nếu bạn chưa xem nó.

Ở đầu luận văn là một trích dẫn:

Hầu như tất cả mọi người đều cảm thấy hòa bình với thiên nhiên: lắng nghe những con sóng đại dương chống lại bờ biển, bên một hồ nước tĩnh lặng, trên một cánh đồng cỏ, trên một ngọn gió lộng gió. Một ngày nọ, khi chúng ta đã học được cách vượt thời gian một lần nữa, chúng ta sẽ cảm thấy như vậy về các thị trấn của chúng ta, và chúng ta sẽ cảm thấy bình yên trong chúng, như ngày nay chúng ta đi bộ trên đại dương, hoặc trải dài trên bãi cỏ dài đồng cỏ.

- Christopher Alexander, Cách xây dựng vượt thời gian (1979)

Và điều đó thực sự tổng hợp nó lên đó. REST theo nhiều cách thanh lịch hơn.

SOAP là một giao thức nằm trên HTTP, do đó, nó bỏ qua rất nhiều quy ước HTTP để xây dựng các quy ước mới trong SOAP và theo một số cách dự phòng với HTTP. Tuy nhiên, HTTP là quá đủ để truy xuất, tìm kiếm, viết và xóa thông tin qua HTTP và đó là rất nhiều REST là gì. Vì REST được xây dựng với HTTP thay vì trên đầu trang, điều đó cũng có nghĩa là phần mềm muốn tích hợp với nó (chẳng hạn như trình duyệt web) không cần phải hiểu SOAP để làm như vậy, chỉ cần HTTP, là phần mềm phải là nhất được hiểu rộng rãi và tích hợp - với giao thức được sử dụng tại thời điểm này.

Từ đây :

Ưu điểm của REST:

• Nhẹ - không có nhiều đánh dấu xml thêm
• Kết quả có thể đọc được của con người
• Dễ dàng xây dựng - không yêu cầu bộ công cụ

Ngoài ra kiểm tra này :

Công bằng mà nói, REST không phải là giải pháp tốt nhất cho mọi dịch vụ Web. Dữ liệu cần được bảo mật không nên được gửi dưới dạng tham số trong URI. Và một lượng lớn dữ liệu, như thế trong các đơn đặt hàng chi tiết, có thể nhanh chóng trở nên cồng kềnh hoặc thậm chí vượt ra ngoài giới hạn trong một URI. Trong những trường hợp này, SOAP thực sự là một giải pháp vững chắc. Nhưng điều quan trọng là phải thử REST trước và chỉ sử dụng SOAP khi cần thiết. Điều này giúp giữ cho sự phát triển ứng dụng đơn giản và dễ tiếp cận.

Tôi có thể nói một cách an toàn rằng tôi đã dành rất nhiều thời gian để hiểu điều này khi mới bắt đầu nhưng đây là liên kết tốt nhất để bắt đầu với REST từ đầu! http://www.codeproject.com/Articles/21174/Everything- About-REST-Web-Service-What-and-How-Pa

Chỉ cần kéo bạn vào,

Hãy nghĩ về "dịch vụ web truyền thống" là gì. Nó là một giao diện với "phương thức" tiếp xúc. Khách hàng biết tên, đầu vào và đầu ra của phương thức và do đó có thể gọi chúng.

Bây giờ hãy tưởng tượng một giao diện không phơi bày "phương thức". Thay vào đó, nó phơi bày "đồ vật". Vì vậy, khi khách hàng nhìn thấy giao diện này, tất cả những gì họ thấy là một hoặc nhiều "đối tượng". "Một đối tượng" không có đầu vào và đầu ra - bởi vì "nó không làm gì cả". Nó là một danh từ, không phải động từ. Đó là "một điều", không phải "một hành động".

Ví dụ, hãy nghĩ đến một dịch vụ web truyền thống cung cấp các điều kiện thời tiết hiện tại nếu bạn cung cấp cho nó một thành phố. Nó có thể có một phương thức web như GetWeatherInfo () lấy một thành phố làm đầu vào và cung cấp dữ liệu thời tiết làm đầu ra. Bạn có thể dễ dàng hiểu được khách hàng sẽ sử dụng dịch vụ web này như thế nào.

Bây giờ hãy tưởng tượng, ở vị trí của dịch vụ web ở trên, có một cái mới phơi bày các thành phố dưới dạng các đối tượng. Vì vậy, khi bạn xem nó như một khách hàng, thay vì GetWeatherInfo (), bạn sẽ thấy New York, Dallas, Los Angeles, London, v.v. Và những thành phố này không có bất kỳ phương pháp cụ thể ứng dụng nào treo chúng - chúng rõ ràng giống như khí trơ - bản thân chúng không phản ứng.

Bạn phải suy nghĩ - tốt, làm thế nào điều đó giúp bạn, với tư cách là khách hàng, để đến với thời tiết của Dallas? Chúng tôi sẽ nhận được điều đó trong một vài khoảnh khắc.

Nếu tất cả những gì bạn nhận được từ một dịch vụ web là một "bộ đối tượng", rõ ràng bạn cần một cách để "hành động theo chúng". Bản thân các đối tượng không có phương thức để bạn gọi, vì vậy bạn cần một tập hợp các hành động mà bạn có thể áp dụng cho các đối tượng này. Nói cách khác, bạn cần "áp dụng một động từ cho danh từ". Nếu bạn thấy một đối tượng, giả sử, một quả táo, là "danh từ", bạn có thể áp dụng "một động từ" như ăn, cho nó. Nhưng không phải tất cả các động từ có thể được áp dụng cho tất cả các danh từ. Giống như, bạn có thể lái xe, nhưng không thể lái tivi.

Do đó, nếu một dịch vụ web chỉ hiển thị các đối tượng và bạn được hỏi - tốt, bây giờ chúng ta hãy thiết kế một vài hành động hoặc động từ tiêu chuẩn mà "tất cả khách hàng có thể áp dụng cho tất cả các đối tượng họ nhìn thấy", ...

Đây là một số ý tưởng:

• REST ràng buộc dịch vụ của bạn để sử dụng giao diện thống nhất. Bạn không phải lãng phí thời gian mơ mộng (hoặc tranh cãi) về tất cả các cách có thể mà dịch vụ của bạn có thể hoạt động - bạn có quyền làm việc xác định các tài nguyên trong hệ thống của mình. Hóa ra đó là một công việc lớn trong chính nó, nhưng may mắn thay, các vấn đề có xu hướng được xác định tốt hơn nhiều.
• Với các nguồn lực, các hiệp hội của họ và các đại diện của họ trong tay, thực sự có rất ít việc phải làm trong việc triển khai dịch vụ của bạn vì nhiều quyết định đã được đưa ra cho bạn.
• Hệ thống của bạn sẽ trông rất giống các hệ thống RESTful khác; đường cong học tập cho đồng đội, đối tác và khách hàng sẽ bị giảm.
• Bạn sẽ có một từ vựng chung để thảo luận về các vấn đề thiết kế với các nhà phát triển khác và ngay cả với những người ít suy nghĩ về kỹ thuật (như khách hàng).
• Như Darrel nói, bởi vì bạn đang sử dụng một siêu văn bản điều khiển thiết kế , dịch vụ của bạn thu hẹp phạm vi khớp nối chỉ với một thứ - các loại phương tiện. Điều này giúp bạn với tư cách là nhà phát triển vì các thay đổi đối với hệ thống của bạn được chứa trong một dải liên hệ hẹp. Điều này giúp khách hàng của bạn trong đó ít thay đổi của bạn sẽ phá vỡ mã của họ.
• Hầu hết mọi vấn đề bạn có thể gặp phải khi triển khai REST đều có thể được giải quyết bằng tài nguyên mới hoặc suy nghĩ lại mô hình tài nguyên của bạn. Trọng tâm này là, IMO, tăng năng suất lớn.

Tóm lại, REST loại bỏ nhiều quyết định thiết kế và thi hành tốn nhiều thời gian và gây tranh cãi nhất khỏi quy trình làm việc của nhóm bạn. Nó chuyển sự chú ý của bạn từ việc thực hiện dịch vụ của bạn sang thiết kế nó. Và nó làm như vậy mà không chồng chất gobbledygook lên giao thức HTTP.

Hầu hết các câu trả lời "pro" về REST dường như đến từ những người chưa bao giờ phát triển dịch vụ web SOAP hoặc máy khách sử dụng môi trường cung cấp các công cụ phù hợp cho nhiệm vụ. Họ phàn nàn về các vấn đề mà đơn giản là tôi chưa bao giờ gặp phải, sử dụng Visual Studio .NET và Rational Web Developer của IBM. Tôi cho rằng nếu bạn phải phát triển các dịch vụ web hoặc ứng dụng khách bằng ngôn ngữ kịch bản hoặc một số ngôn ngữ khác có ít hoặc không có công cụ hỗ trợ, thì đây là những khiếu nại hợp lệ.

Tôi cũng phải thừa nhận rằng một số điểm "pro" nghe giống như những điều thực sự có thể đúng - nhưng tôi chưa bao giờ thấy một ví dụ minh họa giá trị của chúng. Đặc biệt, tôi đánh giá rất cao nếu ai đó đăng bình luận có chứa một liên kết đến một ví dụ hay về dịch vụ web REST. Đây phải là một cấp sử dụng nhiều cấp tài nguyên, có thể trong hệ thống phân cấp và sử dụng đúng loại phương tiện. Có lẽ nếu tôi nhìn vào một ví dụ tốt, tôi sẽ hiểu, trong trường hợp đó, tôi sẽ quay lại đây và thừa nhận nó.

Để thêm một chút xoáy vào các câu trả lời đã được đưa ra với lý do chúng tôi sử dụng các dịch vụ REST trong đó tôi biết rằng nếu bạn biết bạn có thể trao cho một đối tác kinh doanh một URL và biết rằng họ sẽ nhận được một tấm XML độc đáo bất kể họ đang làm việc trong .Net xx, PHP, Python, Java, Ruby hay thần biết - điều gì làm giảm đau đầu nghiêm trọng.

Điều đó cũng có nghĩa là vào cuối phi công nghệ, nhân viên bán hàng của chúng tôi có thể khoe khoang về API đa năng của chúng tôi cho mọi người mà không sợ trông giống như các muppets hoàn chỉnh.

Ngoài những lợi ích kỹ thuật, bất cứ điều gì dễ dàng để một người không chuyên về công nghệ giải thích, chứng minh và cảm thấy tự tin là một điều tốt. SOAP, mặc dù cũng tuyệt vời đối với các nhà công nghệ ít được tiếp cận bởi những người không chuyên về công nghệ và do đó không dễ "bán".

Tôi có xu hướng nhận thấy rằng những thứ mà những người không chuyên có thể có được vòng đầu của họ có xu hướng dính vào. Vì vậy, tôi nghi ngờ REST là một kỹ thuật có thể dễ bị ảnh hưởng như SOAP đối với những ý tưởng bất chợt của thời trang.

Nhưng tất cả những điều về việc không đưa bất cứ thứ gì vào dịch vụ REST nên bị khóa là đúng gấp đôi nếu chỉ vì công nghệ này rất dễ hiểu bởi những người không có đầu óc kỹ thuật.

REST là một kiểu kiến ​​trúc để thiết kế các ứng dụng nối mạng. Ý tưởng là, thay vì sử dụng các cơ chế phức tạp như CORBA, RPC hoặc SOAP để kết nối giữa các máy, HTTP đơn giản được sử dụng để thực hiện cuộc gọi giữa các máy.

Theo nhiều cách, World Wide Web, dựa trên HTTP, có thể được xem như một kiến ​​trúc dựa trên REST. Các ứng dụng RESTful sử dụng các yêu cầu HTTP để đăng dữ liệu (tạo và / hoặc cập nhật), đọc dữ liệu (ví dụ: thực hiện truy vấn) và xóa dữ liệu. Do đó, REST sử dụng HTTP cho cả bốn thao tác CRUD (Tạo / Đọc / Cập nhật / Xóa).

REST là một giải pháp thay thế nhẹ cho các cơ chế như RPC (Cuộc gọi thủ tục từ xa) và Dịch vụ web (SOAP, WSDL, et al.). Sau đó, chúng ta sẽ thấy REST đơn giản hơn nhiều.

Mặc dù đơn giản, REST có đầy đủ tính năng; về cơ bản không có gì bạn có thể làm trong Dịch vụ web không thể thực hiện được với kiến ​​trúc RESTful. REST không phải là "tiêu chuẩn". Chẳng hạn, sẽ không bao giờ có khuyến nghị W3C cho REST. Và trong khi có các khung lập trình REST, làm việc với REST đơn giản đến mức bạn có thể thường xuyên "tự làm" với các tính năng thư viện tiêu chuẩn bằng các ngôn ngữ như Perl, Java hoặc C #.