Sự khác biệt giữa REST và CRUD


168

Tôi đã học REST và cảm giác rất giống CRUD (từ những gì tôi đã đọc về CRUD).

Tôi biết họ khác nhau và tôi tự hỏi nếu nghĩ rằng họ giống nhau có nghĩa là tôi không hiểu họ.

Có phải REST là "siêu nhân" của CRUD không? Có phải mọi thứ CRUD làm và nhiều hơn nữa?


17
Suy nghĩ họ đang có nghĩa tương tự mà bạn làm hiểu chúng. Khi đọc câu trả lời, tôi thấy một điều đáng ngạc nhiên và những gì tôi cho là mức độ không chính xác khi không thừa nhận sự tương đồng giữa các khái niệm. Tôi tin rằng cách chính xác để hiểu REST nghĩ về nó như là "CRUD cho tài nguyên HTTP". Nếu bạn hiểu tài nguyên HTTP là gì (rõ ràng không giống với bản ghi cơ sở dữ liệu) và bạn biết CRUD là gì, thì mô tả REST là "CRUD cho tài nguyên HTTP" là một cách chính xác và ngắn gọn để truyền đạt bản chất của REST.
Jason Livesay

Câu trả lời:


205

Đáng ngạc nhiên, tôi không thấy trong các câu trả lời khác những gì tôi cho là sự khác biệt thực sự giữa REST và CRUD: những gì mỗi người quản lý.

CRUD có nghĩa là các hoạt động cơ bản được thực hiện trong kho lưu trữ dữ liệu. Bạn trực tiếp xử lý hồ sơ hoặc đối tượng dữ liệu; ngoài các hoạt động này, các hồ sơ là các thực thể thụ động. Thông thường, nó chỉ là bảng cơ sở dữ liệu và hồ sơ.

Mặt khác, REST hoạt động dựa trên các biểu diễn tài nguyên, mỗi cái được xác định bởi một URL. Đây thường không phải là đối tượng dữ liệu, mà là trừu tượng đối tượng phức tạp.

Ví dụ, một tài nguyên có thể là một nhận xét của người dùng. Điều đó có nghĩa là không chỉ một bản ghi trong bảng 'bình luận', mà cả các mối quan hệ của nó với tài nguyên 'người dùng', bài đăng mà bình luận được đính kèm, có thể là một bình luận khác mà nó phản hồi.

Hoạt động trên nhận xét không phải là hoạt động cơ sở dữ liệu nguyên thủy, nó có thể có tác dụng phụ đáng kể, như đưa ra cảnh báo cho người đăng ban đầu hoặc tính toán lại một số 'điểm' giống như trò chơi hoặc cập nhật một số 'luồng người theo dõi'.

Ngoài ra, biểu diễn tài nguyên bao gồm siêu văn bản (kiểm tra nguyên tắc HATEOAS ), cho phép nhà thiết kế thể hiện mối quan hệ giữa các tài nguyên hoặc hướng dẫn máy khách REST trong quy trình làm việc của hoạt động.

Nói tóm lại, CRUD là một hoạt động nguyên thủy được thiết lập (chủ yếu dành cho cơ sở dữ liệu và lưu trữ dữ liệu tĩnh), trong khi REST là kiểu API cấp cao (chủ yếu dành cho các dịch vụ web và các hệ thống 'sống' khác).

Cái đầu tiên thao tác dữ liệu cơ bản, cái còn lại tương tác với một hệ thống phức tạp.


3
@Javier Cảm ơn bạn đã đặt chúng ra. Tôi đã sử dụng Rails learning REST và tôi có ấn tượng rằng nó là sự thay thế cho CRUD (mà tôi đã học được từ ... cái tên đó, tôi đã sử dụng nó, chỉ không biết nên gọi nó là gì) ... Bạn đã biến REST vs CRUD từ so sánh 2 quả táo sang so sánh táo và cam. Cảm ơn
Jesse Black

2
@Maudicus: Tôi nghĩ nó rất phổ biến, vì RoR bao gồm một lớp CRUD (như hầu hết (mọi?) Khung) và việc thêm API REST lên trên đó thật dễ dàng, dễ dàng nghĩ rằng đó là điều dễ dàng tất cả những gì REST là. Nhưng sau đó, bạn có thể thêm chức năng trên CRUD nhưng đằng sau API REST, làm cho chúng ngày càng khác biệt hơn.
Javier

1
Câu trả lời của bạn là đúng, nhưng ví dụ không tối ưu: một nhận xét có thể rút gọn thành một hàng db duy nhất và không thể thực hiện các thay đổi động đối với các đối tượng liên quan bằng trình kích hoạt db? Tôi cảm thấy có nhiều hơn một chút so với chỉ hoạt động thô trong api yên tĩnh, và câu trả lời của bạn rõ ràng mang cảm giác đó tốt.
didierc

2
Vì vậy, ... điều tương tự, lớp khác nhau :)
AlikElzin-kilaka

Cảm ơn bạn rất nhiều vì đã thể hiện điều này! Tôi muốn nói thêm rằng việc giới hạn các động từ HTTP đối với các hoạt động CRUD dẫn đến việc triển khai REST theo nghĩa đen là CRUD, với rất nhiều công cụ khái quát hóa bản tóm tắt CRUD và bỏ lỡ một vị trí cho logic "hoạt động trên một nhận xét" tùy chỉnh này.
sompylasar

99

Trước hết, cả hai chỉ đơn giản là tên viết tắt phổ biến; họ không có gì phải sợ.

Bây giờ, CRUD là một thuật ngữ đơn giản được viết tắt bởi vì đây là một tính năng phổ biến trong nhiều ứng dụng và nói CRUD dễ dàng hơn . Nó mô tả 4 thao tác cơ bản bạn có thể thực hiện trên dữ liệu (hoặc tài nguyên). Tạo, đọc, cập nhật, xóa.

Tuy nhiên, REST là một thông lệ có tên (giống như AJAX), bản thân nó không phải là một công nghệ. Nó khuyến khích sử dụng các khả năng đã có từ lâu trong giao thức HTTP, nhưng hiếm khi được sử dụng.

Khi bạn có một URL (Bộ định vị tài nguyên đồng nhất ) và bạn trỏ trình duyệt của mình tới nó theo dòng địa chỉ, bạn đang gửi một yêu cầu HTTP . Mỗi yêu cầu HTTP chứa thông tin mà máy chủ có thể sử dụng để biết phản hồi HTTP nào sẽ gửi lại cho máy khách đã đưa ra yêu cầu.

Mỗi yêu cầu chứa một URL, vì vậy máy chủ biết bạn muốn truy cập tài nguyên nào, nhưng nó cũng có thể chứa một phương thức . Một phương pháp mô tả những gì cần làm với tài nguyên đó.

Nhưng khái niệm "phương pháp" này không được sử dụng rất thường xuyên.

Thông thường, mọi người sẽ chỉ liên kết đến các trang thông qua phương thức GET và đưa ra bất kỳ loại cập nhật nào (xóa, chèn, cập nhật) thông qua phương thức POST.

Và do đó, bạn không thể coi một tài nguyên (URL) là tài nguyên thực sự. Bạn phải có các URL riêng để xóa, chèn hoặc cập nhật cùng một tài nguyên. Ví dụ:

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

Với REST, bạn tạo các biểu mẫu thông minh hơn vì chúng sử dụng các phương thức HTTP khác ngoài POST và lập trình máy chủ của bạn để có thể phân biệt giữa các phương thức , không chỉ URLS. Ví dụ:

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

Hãy nhớ rằng, một URL duy nhất mô tả một tài nguyên. Một bài viết là một tài nguyên duy nhất. Với REST, bạn xử lý tài nguyên theo cách chúng được xử lý. Bạn đang nói với máy chủ tài nguyên nào bạn muốn xử lý và cách xử lý.

Có nhiều tính năng khác đối với "Kiến trúc RESTful", mà bạn có thể đọc trong Wikipedia, các bài viết hoặc sách khác, nếu bạn quan tâm. Mặt khác, không có nhiều thứ nữa cho CRUD.


4
xin lỗi, nhưng yên nhiều hơn CRUD. chủ yếu là vì tài nguyên thể hiện nhiều hơn một bản ghi và mỗi thao tác thực hiện nhiều hơn so với cập nhật một bản ghi.
Javier

11
Đồng ý. Tôi đồng ý. Tại sao bạn lại xin lỗi? Tôi đã không nói rằng nó không nhiều hơn CRUD. Tôi nghĩ đó chính xác là những gì tôi đã nói.
Yam Marcovic

4
Đây phải là câu trả lời đúng.
Brandon

Đặc tả HTML chỉ cho phép các phương thức GET và POST để gửi biểu mẫu, vì vậy các phương thức khác không được sử dụng trong các yêu cầu xử lý dịch vụ từ webclents trước khi AJAX trở nên phổ biến. Một số dịch vụ sử dụng trường nhập liệu ẩn có tên "_method" làm cách giải quyết để chỉ định một phương thức khác với POST trong khi vẫn gửi biểu mẫu bằng phương thức POST.
Kenneth Sundqvist

20

REST là viết tắt của "chuyển trạng thái đại diện", có nghĩa là tất cả về giao tiếp và sửa đổi trạng thái của một số tài nguyên trong một hệ thống.

REST khá liên quan, bởi vì lý thuyết đằng sau REST được sử dụng để tận dụng phương tiện truyền thông, hypermedia và một giao thức cơ bản để quản lý thông tin trên một hệ thống từ xa.

CRUD, mặt khác, là một bản ghi nhớ cho các hoạt động phổ biến bạn cần cho dữ liệu trong cơ sở dữ liệu: Tạo Lấy bản cập nhật Xóa. Nhưng nó thực sự không sâu hơn thế.

Vì vậy, đó là câu trả lời cho câu hỏi của bạn, nhưng tôi sẽ đề cập đến lỗi phổ biến mà tôi thấy khi REST và CRUD được thảo luận cùng nhau. Rất nhiều nhà phát triển muốn ánh xạ REST trực tiếp tới CRUD, vì REST qua HTTP cung cấp cho GET PUT POST và DELETE, trong khi CRUD cung cấp cho CREATE RETRIEVE CẬP NHẬT XÓA. Thật tự nhiên khi muốn ánh xạ các động từ REST trực tiếp đến các hoạt động CRUD.

Tuy nhiên, HTTP sử dụng kiểu "tạo hoặc cập nhật", trong khi CRUD tách biệt tạo và cập nhật. Điều đó làm cho không thể (!) Để tạo một ánh xạ chung, rõ ràng giữa hai (!)

NHẬN và XÓA dễ dàng ... NHẬN === RETRIEVE và XÓA === XÓA.

Nhưng theo thông số HTTP, PUT thực sự là Tạo VÀ Cập nhật:

  • Sử dụng PUT để tạo một đối tượng hoàn toàn mới khi bạn biết mọi thứ về nó, bao gồm cả định danh của nó

  • Sử dụng PUT để cập nhật một đối tượng (thường có biểu diễn hoàn chỉnh của đối tượng)

POST là động từ "đang xử lý" và được coi là động từ "chắp thêm":

  • Sử dụng POST để chắp thêm một đối tượng mới vào bộ sưu tập - nghĩa là tạo một đối tượng mới

  • POST cũng được sử dụng khi không có động từ nào khác phù hợp, vì đặc tả HTTP định nghĩa nó là động từ "xử lý dữ liệu"

  • Nếu nhóm của bạn đang bị treo lên trên POST, hãy nhớ rằng toàn bộ WWW đã được xây dựng trên GET và POST;)

Vì vậy, trong khi có sự tương đồng giữa REST và CRUD, thì lỗi mà tôi thấy hầu hết các đội mắc phải là tạo ra sự tương đương giữa hai nhóm. Một nhóm thực sự cần phải cẩn thận khi xác định API REST không bị treo quá nhiều trong bản ghi nhớ CRUD, bởi vì REST như một thực tiễn thực sự có rất nhiều phức tạp bổ sung mà không ánh xạ rõ ràng vào CRUD.


7

CRUD chỉ định một bộ động từ lưu trữ cơ bản tối thiểu để đọc và ghi dữ liệu: tạo, đọc, cập nhật và xóa. Sau đó, bạn có thể xây dựng các hoạt động khác bằng cách tổng hợp những hoạt động này. Chúng thường được coi là hoạt động cơ sở dữ liệu, nhưng những gì được coi là cơ sở dữ liệu là tùy ý (ví dụ: có thể là DBMS quan hệ, nhưng cũng có thể là tệp YAML).

REST là một "kiểu kiến ​​trúc" thường bao gồm các hoạt động CRUD và các hoạt động cấp cao hơn khác, tất cả được thực hiện trên một số khái niệm về "tài nguyên" (tùy ý, nhưng đây là các thực thể trong ứng dụng của bạn). REST có một loạt các ràng buộc làm cho nó thú vị (và đặc biệt được kết hợp tốt với HTTP).

Giao diện REST có thể, nhưng không phải, phơi bày tất cả các hoạt động CRUD trên một tài nguyên cụ thể. Những gì có sẵn trong giao diện REST là tùy ý và có thể thay đổi do quyền hệ thống, cân nhắc giao diện người dùng và mức độ nóng của nó vào ngày giao diện được thiết kế và tạo. Ngày nóng hơn dẫn đến giao diện tối giản hơn, thông thường, mặc dù điều ngược lại có thể đúng.


Cảm ơn anh. Có vẻ như "Mọi thứ CRUD có làm được không?" là có, với tính kỹ thuật của REST áp dụng cho nhiều mục hơn là chỉ các mục trong cơ sở dữ liệu.
Jesse Black

@Maudicus Tôi đã cập nhật câu trả lời, nhưng phải cụ thể: nó có thể nhưng KHÔNG CÓ.
Dan Rosenstark

Tôi không nói rằng họ yêu cầu ứng dụng của bạn được coi là hoàn chỉnh. Một số ứng dụng không cần chèn, xóa hoặc cập nhật, theo bản chất.
Yam Marcovic

@Yam Marcovic, được rồi, đã điều chỉnh
Dan Rosenstark

6

CRUD

  • CRUD là bốn loại lệnh SQL cơ bản: Tạo, Đọc, Cập nhật và Xóa
  • Hầu hết các ứng dụng có một số loại chức năng CRUD
  • Ứng dụng CRUD là ứng dụng sử dụng biểu mẫu để nhận dữ liệu vào và ra khỏi cơ sở dữ liệu

NGHỈ NGƠI

  • REST là viết tắt của Chuyển giao trạng thái đại diện. (Đôi khi nó được đánh vần là "ReST")

  • Nó dựa trên một giao thức truyền thông không thể lưu trữ, máy khách-máy chủ, không lưu trữ - và trong hầu hết mọi trường hợp, giao thức HTTP được sử dụng

  • REST là một kiểu kiến ​​trúc để thiết kế các ứng dụng nối mạng


2

REST là một cái gì đó giống như một trang web cho các máy mà họ có thể duyệt, trong khi CRUD là một cái gì đó giống như SOAP, được kết hợp chặt chẽ với các máy khách của nó. Đây là những khác biệt chính. Tất nhiên Chúng tương tự nhau trên bề mặt, nhưng CRUD mô tả thao tác thực thể cơ bản, trong khi REST có thể mô tả giao diện của bất kỳ ứng dụng nào. Một điểm khác biệt nữa là REST có thể sử dụng nhiều hơn 4 phương thức HTTP. Sẽ là một câu trả lời rất dài nếu tôi muốn thu thập tất cả sự khác biệt, nếu bạn kiểm tra các câu hỏi về REST vs SOAP, thì bạn sẽ tìm thấy hầu hết trong số chúng.

Tôi nghĩ rằng nhầm lẫn REST với CRUD là một lỗi rất phổ biến và nguyên nhân là các nhà phát triển không có thời gian để đọc sâu về REST. Họ chỉ muốn sử dụng công nghệ - mà không hiểu về nó - dựa trên các ví dụ kiểu CRUD giới hạn được viết bởi các nhà phát triển tương tự. Phần lớn các ví dụ và hướng dẫn đang phản ánh sự thiếu hiểu biết nghiêm trọng. Ánh xạ tài nguyên REST tới các thực thể và phương thức HTTP thành các hoạt động CRUD của các thực thể này và sử dụng REST mà không có siêu liên kết chỉ là một triệu chứng của điều đó. Bằng REST, bạn ánh xạ các siêu liên kết (bao gồm các liên kết với các phương thức POST / PUT / DELETE / PATCH) cho các hoạt động của bạn và bạn xác định hoạt động ở phía máy khách bằng cách kiểm tra mối quan hệ liên kết (thường là API cụ thể). Nếu máy khách REST không biết mối quan hệ liên kết là gì và chỉ biết các phương thức HTTP và có thể một số mẫu URI, thì đó không phải là máy khách REST, mà là CRUD trên máy khách HTTP. Một lỗi phổ biến khác mà máy khách REST là một ứng dụng javascript duy nhất đang chạy trong trình duyệt. Tất nhiên bạn có thể triển khai một ứng dụng khách như vậy, nhưng REST chủ yếu dành cho các máy khách tự động (các ứng dụng phía máy chủ được viết bởi các nhà phát triển mà bạn thậm chí không biết) và không dành cho các máy khách thủ công (các ứng dụng trình duyệt do người dùng kiểm soát do bạn viết). Chỉ có một ứng dụng trình duyệt duy nhất có thể là một dấu hiệu cho thấy bạn không thực sự cần REST và bạn chỉ áp đảo dự án. Trong những trường hợp này, API CRUD là một giải pháp khả thi và các nhà phát triển đang gọi các API CRUD này là REST, vì họ không biết sự khác biệt. Tất nhiên bạn có thể triển khai một ứng dụng khách như vậy, nhưng REST chủ yếu dành cho các máy khách tự động (các ứng dụng phía máy chủ được viết bởi các nhà phát triển mà bạn thậm chí không biết) và không dành cho các máy khách thủ công (các ứng dụng trình duyệt do người dùng kiểm soát do bạn viết). Chỉ có một ứng dụng trình duyệt duy nhất có thể là một dấu hiệu cho thấy bạn không thực sự cần REST và bạn chỉ áp đảo dự án. Trong những trường hợp này, API CRUD là một giải pháp khả thi và các nhà phát triển đang gọi các API CRUD này là REST, vì họ không biết sự khác biệt. Tất nhiên bạn có thể triển khai một ứng dụng khách như vậy, nhưng REST chủ yếu dành cho các máy khách tự động (các ứng dụng phía máy chủ được viết bởi các nhà phát triển mà bạn thậm chí không biết) và không dành cho các máy khách thủ công (các ứng dụng trình duyệt do người dùng kiểm soát do bạn viết). Chỉ có một ứng dụng trình duyệt duy nhất có thể là một dấu hiệu cho thấy bạn không thực sự cần REST và bạn chỉ áp đảo dự án. Trong những trường hợp này, API CRUD là một giải pháp khả thi và các nhà phát triển đang gọi các API CRUD này là REST, vì họ không biết sự khác biệt.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.