Rõ ràng, REST chỉ là một tập hợp các quy ước về cách sử dụng HTTP . Tôi tự hỏi những lợi thế mà các công ước này cung cấp. Có ai biết không?
Câu trả lời:
Tôi không nghĩ bạn sẽ nhận được câu trả lời tốt cho vấn đề này, một phần vì không ai thực sự đồng ý với REST là gì . Các trang wikipedia là nặng về thuật ngữ thông dụng và ánh sáng trên giải thích. Trang thảo luận đáng để đọc lướt qua để xem mọi người không đồng ý với điều này như thế nào. Tuy nhiên, theo như tôi có thể nói, REST có nghĩa như sau:
Thay vì có URL setter và getter tên ngẫu nhiên và sử dụng GETcho tất cả các getter và POSTcho tất cả các setters, chúng tôi cố gắng để có URL này xác định các nguồn lực, và sau đó sử dụng các hành động HTTP GET, POST, PUTvà DELETEđể làm công cụ cho họ. Vì vậy, thay vì
GET /get_article?id=1
POST /delete_article id=1
Bạn sẽ làm
GET /articles/1/
DELETE /articles/1/
Và sau đó POSTvà PUTtương ứng với các hoạt động "tạo" và "cập nhật" (nhưng không ai đồng ý theo cách nào).
Tôi nghĩ rằng các đối số bộ nhớ đệm là sai, vì các chuỗi truy vấn được thường lưu trữ, và bên cạnh đó bạn không thực sự cần phải sử dụng chúng. Ví dụ, django làm cho một cái gì đó như thế này rất dễ dàng, và tôi sẽ không nói đó là REST:
GET /get_article/1/
POST /delete_article/ id=1
Hoặc thậm chí chỉ bao gồm động từ trong URL:
GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/
Trong trường hợp GETđó có nghĩa là một cái gì đó không có tác dụng phụ và POSTcó nghĩa là một cái gì đó thay đổi dữ liệu trên máy chủ. Tôi nghĩ rằng đây có lẽ là rõ ràng hơn một chút và dễ dàng hơn, đặc biệt là khi bạn có thể tránh được toàn bộ PUTchuyến bay từ POSTđiều. Ngoài ra, bạn có thể thêm nhiều động từ nếu bạn muốn, vì vậy bạn không bị ràng buộc giả tạo với những gì HTTP cung cấp. Ví dụ:
POST /hide/article/1/
POST /show/article/1/
(Hoặc bất cứ điều gì, thật khó để nghĩ về các ví dụ cho đến khi chúng xảy ra!)
Vì vậy, kết luận, chỉ có hai lợi thế tôi có thể thấy:
synchronize("/articles/1/")hoặc bất cứ điều gì. Điều này phụ thuộc rất nhiều vào mã của bạn.Tuy nhiên tôi nghĩ có một số nhược điểm khá lớn:
PUTvà tròn POST. Trong tiếng Anh, chúng có nghĩa tương tự ("Tôi sẽ đặt / đăng thông báo lên tường.").Vì vậy, để kết luận tôi sẽ nói: trừ khi bạn thực sự muốn nỗ lực thêm hoặc nếu dịch vụ của bạn ánh xạ thực sự tốt đến các hoạt động CRUD, hãy lưu REST cho phiên bản API thứ hai của bạn.
Tôi vừa gặp một vấn đề khác với REST: Không dễ để thực hiện nhiều hơn một điều trong một yêu cầu hoặc chỉ định phần nào của đối tượng ghép bạn muốn nhận. Điều này đặc biệt quan trọng trên thiết bị di động nơi thời gian khứ hồi có thể là đáng kể và các kết nối không đáng tin cậy. Ví dụ: giả sử bạn đang nhận được bài đăng trên dòng thời gian của facebook. Cách REST "thuần túy" sẽ giống như
GET /timeline_posts // Returns a list of post IDs.
GET /timeline_posts/1/ // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....
Đó là loại vô lý. API của Facebook là IMO khá tuyệt vời, vì vậy hãy xem họ làm gì:
Theo mặc định, hầu hết các thuộc tính đối tượng được trả về khi bạn thực hiện một truy vấn. Bạn có thể chọn các trường (hoặc kết nối) bạn muốn trả về với tham số truy vấn "trường". Ví dụ: URL này sẽ chỉ trả về id, tên và hình ảnh của Ben: https://graph.facebook.com/bgolub?fields=id,name,picture
Tôi không biết làm thế nào bạn sẽ làm một cái gì đó như thế với REST và nếu bạn đã làm liệu nó vẫn được tính là REST. Tôi chắc chắn sẽ bỏ qua bất cứ ai cố gắng nói với bạn rằng bạn không nên làm điều đó (đặc biệt nếu lý do là "vì đó không phải là REST")!
/user/{id}, thì nó không yên tâm. Hãy xem xét: trình duyệt của bạn có phải được lập trình sẵn để biết cách lấy HTML cho câu hỏi stackoverflow không trang?
Nói một cách đơn giản, REST có nghĩa là sử dụng HTTP theo cách nó có nghĩa.
Hãy xem luận văn của Roy Fielding về REST . Tôi nghĩ rằng mọi người đang phát triển web nên đọc nó.
Lưu ý, Roy Fielding cũng là một trong những trình điều khiển chính đằng sau giao thức HTTP.
Để đặt tên cho một số lời khuyên:
Đơn giản chỉ cần đặt: KHÔNG .
Hãy thoải mái tải xuống, nhưng tôi vẫn nghĩ rằng không có lợi ích thực sự nào so với HTTP HTTP không. Tất cả các câu trả lời hiện tại là không hợp lệ. Lập luận từ câu trả lời được bình chọn nhiều nhất hiện nay:
Với REST, bạn cần lớp giao tiếp bổ sung cho các tập lệnh phía máy chủ và phía máy khách => nó thực sự phức tạp hơn so với việc sử dụng HTTP không phải REST.
Bộ nhớ đệm có thể được kiểm soát bởi các tiêu đề HTTP được gửi bởi máy chủ. REST không thêm bất kỳ tính năng nào bị thiếu trong non-REST.
REST không giúp bạn sắp xếp mọi thứ. Nó buộc bạn phải sử dụng API được hỗ trợ bởi thư viện phía máy chủ mà bạn đang sử dụng. Bạn có thể sắp xếp ứng dụng của mình theo cùng một cách (hoặc tốt hơn) khi bạn đang sử dụng phương pháp không phải REST. Ví dụ, xem định tuyến Model-View-Controller hoặc MVC .
Không đúng chút nào. Tất cả phụ thuộc vào mức độ bạn tổ chức và tài liệu ứng dụng của bạn. REST sẽ không làm cho ứng dụng của bạn tốt hơn.
IMHO lợi thế lớn nhất mà REST cho phép là giảm khớp nối máy khách / máy chủ. Việc phát triển giao diện REST theo thời gian sẽ dễ dàng hơn nhiều mà không phá vỡ các máy khách hiện có.
Mỗi tài nguyên có tham chiếu đến các tài nguyên khác, theo phân cấp hoặc liên kết, vì vậy thật dễ dàng để duyệt xung quanh. Đây là một lợi thế cho con người phát triển khách hàng, giúp anh ta / cô ta không ngừng tư vấn các tài liệu và đưa ra các đề xuất. Điều đó cũng có nghĩa là máy chủ có thể đơn phương thay đổi tên tài nguyên (miễn là phần mềm máy khách không mã hóa các URL).
Bạn có thể HỎI theo cách của bạn vào bất kỳ phần nào của API hoặc sử dụng trình duyệt web để điều hướng các tài nguyên. Làm cho việc gỡ lỗi và kiểm tra tích hợp dễ dàng hơn nhiều.
Cho phép bạn chỉ định các hành động mà không cần phải tìm từ ngữ chính xác. Hãy tưởng tượng nếu Oetters getters và setters không được tiêu chuẩn hóa, và một số người đã sử dụng retrievevàdefine thay vào đó. Bạn sẽ phải ghi nhớ động từ chính xác cho từng điểm truy cập riêng lẻ. Biết rằng chỉ có một số ít động từ có sẵn vấn đề.
Nếu bạn GETlà tài nguyên không tồn tại, bạn có thể chắc chắn gặp 404lỗi trong API RESTful. Đối chiếu nó với API không RESTful, có thể quay trở lại {error: "Not found"}được bao bọc trong Chúa biết có bao nhiêu lớp. Nếu bạn cần thêm không gian để viết tin nhắn cho nhà phát triển ở phía bên kia, bạn luôn có thể sử dụng phần thân của phản hồi.
Hãy tưởng tượng hai API có cùng chức năng, một API theo sau và API còn lại thì không. Bây giờ hãy tưởng tượng các ứng dụng khách sau cho các API đó:
PHỤC HỒI:
GET /products/1052/reviews
POST /products/1052/reviews "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10
HTTP:
GET /reviews?product_id=1052
POST /post_review?product_id=1052 "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10
Bây giờ nghĩ về các câu hỏi sau đây:
Nếu cuộc gọi đầu tiên của mỗi khách hàng hoạt động, làm thế nào chắc chắn bạn có thể là những người còn lại cũng sẽ làm việc?
Có một bản cập nhật lớn cho API có thể thay đổi các điểm truy cập đó. Bao nhiêu tài liệu bạn sẽ phải đọc lại?
Bạn có thể dự đoán sự trở lại của truy vấn cuối cùng?
Bạn phải chỉnh sửa đánh giá được đăng (trước khi xóa nó). Bạn có thể làm như vậy mà không cần kiểm tra các tài liệu?
Tôi khuyên bạn nên xem qua cách tôi giải thích REST cho vợ tôi của Ryan Tomayko
Trích từ liên kết waybackmaschine:
Làm thế nào về một ví dụ. Bạn là giáo viên và muốn quản lý học sinh:
Nếu các hệ thống dựa trên web, thì có lẽ có một URL cho mỗi danh từ liên quan ở đây : student, teacher, class, book, room, etc. ... Nếu có một đại diện có thể đọc được bằng máy cho mỗi URL, thì việc chốt các công cụ mới vào hệ thống sẽ là chuyện nhỏ vì tất cả thông tin đó sẽ được tiêu thụ theo cách tiêu chuẩn. ... Bạn có thể xây dựng một hệ thống toàn quốc có thể nói chuyện với từng hệ thống trường học riêng lẻ để thu thập điểm kiểm tra.
Mỗi hệ thống sẽ nhận thông tin từ nhau bằng cách sử dụng HTTP GET đơn giản. Nếu một hệ thống cần thêm một cái gì đó vào hệ thống khác, nó sẽ sử dụng HTTP POST. Nếu một hệ thống muốn cập nhật một cái gì đó trong một hệ thống khác, nó sử dụng PUT HTTP. Điều duy nhất còn lại để tìm ra là dữ liệu sẽ trông như thế nào.
Tôi muốn đề nghị tất cả mọi người, những người đang tìm kiếm câu trả lời cho câu hỏi này, hãy xem qua "slideshow" này .
Tôi không thể hiểu REST là gì và tại sao nó lại tuyệt vời, ưu và nhược điểm của nó, khác với SOAP - nhưng trình chiếu này rất tuyệt vời và dễ hiểu, vì vậy bây giờ nó rõ ràng hơn nhiều so với trước đây.
Bộ nhớ đệm.
Có nhiều lợi ích khác về chiều sâu của REST xoay quanh khả năng tiến hóa thông qua khớp nối lỏng lẻo và siêu văn bản, nhưng các cơ chế lưu trữ là lý do chính mà bạn nên quan tâm về RESTful HTTP.
GET /get_article/19/và POST /update_articlenếu bộ nhớ đệm là mối quan tâm của bạn. Bạn vẫn có thể làm tất cả mọi thứ chỉ với GETvà POSTvà tôi tin RESTcó nghĩa là "Sử dụng GET, POST, PUTvà DELETEduy nhất." và không chỉ "Không sử dụng chuỗi truy vấn." Vì vậy, những gì tôi đề nghị sẽ không được REST. Sau đó, một lần nữa, không ai có thể thực sự đồng ý những gì REST là vì vậy tôi đặt nó vào một cái xô với "Web 2.0".
Nó được viết trong luận văn Fielding . Nhưng nếu bạn không muốn đọc nhiều:
Có thể làm mọi thứ chỉ với POST và GET? Vâng, nó là cách tiếp cận tốt nhất? Không, tại sao? bởi vì chúng tôi có các phương pháp tiêu chuẩn. Nếu bạn nghĩ lại, có thể làm mọi thứ chỉ bằng cách NHẬN .. vậy tại sao chúng ta thậm chí phải bận tâm sử dụng POST? Vì tiêu chuẩn!
Ví dụ, ngày nay nghĩ về một mô hình MVC, bạn có thể giới hạn ứng dụng của mình chỉ phản hồi với các loại động từ cụ thể như POST, GET, PUT và DELETE. Ngay cả khi dưới mui xe, mọi thứ đều được mô phỏng theo POST và GET, không có nghĩa là có các động từ khác nhau cho các hành động khác nhau?
Khám phá dễ dàng hơn nhiều trong REST. Chúng tôi có các tài liệu WADL (tương tự WSDL trong các dịch vụ web truyền thống) sẽ giúp bạn quảng cáo dịch vụ của mình ra thế giới. Bạn cũng có thể sử dụng những khám phá UDDI. Với HTTP POST và GET truyền thống, mọi người có thể không biết sơ đồ phản hồi và yêu cầu tin nhắn của bạn để gọi cho bạn.
Một lợi thế là, chúng ta có thể xử lý không tuần tự các tài liệu XML và dữ liệu XML không theo thứ tự từ các nguồn khác nhau như đối tượng InputStream, URL, nút DOM ...
@Timmmm, về chỉnh sửa của bạn:
GET /timeline_posts // could return the N first posts, with links to fetch the next/previous N posts
Điều này sẽ làm giảm đáng kể số lượng cuộc gọi
Và không có gì ngăn cản bạn thiết kế một máy chủ chấp nhận các tham số HTTP để biểu thị các giá trị trường mà khách hàng của bạn có thể muốn ...
Nhưng đây là một chi tiết.
Quan trọng hơn nhiều là thực tế là bạn đã không đề cập đến những lợi thế to lớn của phong cách kiến trúc REST (khả năng mở rộng tốt hơn nhiều, do trạng thái không trạng thái của máy chủ; tính khả dụng tốt hơn nhiều, do trạng thái không trạng thái của máy chủ; sử dụng tốt hơn các dịch vụ tiêu chuẩn, như bộ nhớ đệm cho chẳng hạn, khi sử dụng kiểu kiến trúc REST, khớp nối giữa máy khách và máy chủ thấp hơn nhiều, do sử dụng giao diện thống nhất, v.v.)
Đối với nhận xét của bạn
"Không phải tất cả các hành động đều dễ dàng ánh xạ tới CRUD (tạo, đọc / truy xuất, cập nhật, xóa)."
: RDBMS cũng sử dụng cách tiếp cận CRUD (CHỌN / CHERTN / XÓA / CẬP NHẬT) và luôn có cách để biểu diễn và hành động theo mô hình dữ liệu.
Về câu của bạn
"Bạn thậm chí có thể không xử lý các tài nguyên loại đối tượng"
: về bản chất, một thiết kế RESTful là một thiết kế đơn giản - nhưng điều này KHÔNG có nghĩa là thiết kế nó đơn giản. Bạn có thấy sự khác biệt ? Bạn sẽ phải suy nghĩ rất nhiều về các khái niệm mà ứng dụng của bạn sẽ đại diện và xử lý, những gì phải được thực hiện bởi nó, nếu bạn thích, để thể hiện điều này bằng các tài nguyên. Nhưng nếu bạn làm như vậy, bạn sẽ kết thúc với một thiết kế đơn giản và hiệu quả hơn.
Chuỗi truy vấn có thể bị bỏ qua bởi các công cụ tìm kiếm.