REST là gì? Hơi bối rối [đóng cửa]


155

Tôi đã giả định rằng REST là một dịch vụ web nhưng dường như tôi không đúng khi nghĩ về điều này - vậy, REST là gì?

Tôi đã đọc qua Wikipedia nhưng vẫn không thể quấn đầu xung quanh nó. Tại sao nhiều nơi gọi API là API của REST?


21
@ John Saunders: Làm thế nào đây là một bản sao có thể? Anh chàng kia rõ ràng biết REST là gì trong khi đó, mặt khác, lại bối rối.
Mã giả Monkey Rashid

Tôi cảm thấy người kia sẽ trả lời câu hỏi của anh ấy. Nếu không có ai khác đồng ý, thì cuộc bỏ phiếu chặt chẽ sẽ bị hủy bỏ. Chúng tôi có khoảng mười câu trả lời cho câu hỏi này. Chỉ cần nhấp vào thẻ "phần còn lại" và bạn sẽ thấy tất cả.
John Saunders

1
REST là một bộ quy tắc để xây dựng các dịch vụ web. Nếu một API được xây dựng theo các quy tắc đó thì đó là API REST. Làm thế nào tôi giải thích REST cho con vịt cao su của tôi giải thích một số quy tắc không chính thức.
Người dùng42

Câu trả lời:


127

REST không phải là một dịch vụ web cụ thể mà là một khái niệm thiết kế (kiến trúc) để quản lý thông tin trạng thái. Bài báo chuyên đề về vấn đề này là luận án của Roy Thomas Fielding (2000), "Phong cách kiến ​​trúc và thiết kế kiến ​​trúc phần mềm dựa trên mạng" ( có sẵn trực tuyến từ Đại học California, Irvine).

Lần đầu tiên đọc bài viết của Ryan Tomayko Tôi đã giải thích REST cho vợ tôi như thế nào ; đó là một điểm khởi đầu tuyệt vời. Sau đó đọc luận văn thực tế của Fielding. Nó không tiên tiến, cũng không dài (sáu chương, 180 trang)! (Tôi biết bạn trẻ ở trường thích nó ngắn).

EDIT: Tôi cảm thấy thật vô nghĩa khi cố gắng giải thích REST. Nó có rất nhiều khái niệm như khả năng mở rộng, khả năng hiển thị (không trạng thái), vv mà người đọc cần phải nắm bắt, và nguồn tốt nhất để hiểu những thứ đó là luận án thực tế. Nó nhiều hơn POST / GET, v.v.


@Nathan, hãy tin tôi, tôi đã có cùng một vấn đề như bạn đã làm trước đây. Đọc luận án, có thể đi qua nó một vài lần từ từ, nhưng bạn sẽ nắm bắt được khái niệm, nó thực sự không khó chút nào. Mọi người chỉ có xu hướng giải thích nó kém.
Anders

Khi các nhà phát triển cố gắng sử dụng REST và cố gắng chỉ làm điều đó trên mã của họ (không có kế hoạch cho toàn bộ hệ thống với REST), địa ngục xuất hiện :-)
karatedog

@Anders, Xem xét REST là gì, làm thế nào bạn có thể kết hợp REST vs Dịch vụ web?
Tù nhân


1
có lẽ chương này sẽ là đủ thay vì đọc toàn bộ luận văn: ics.uci.edu/~fielding/pub/dissertation/rest_arch_style.htmlm
andilabs

74

REST là một mẫu thiết kế phần mềm thường được sử dụng cho các ứng dụng web. Theo thuật ngữ của giáo dân, điều này có nghĩa là đó là một ý tưởng thường được sử dụng trong nhiều dự án khác nhau. Nó là viết tắt của Chuyển giao Nhà nước REpresentational . Ý tưởng cơ bản của REST là xử lý các đối tượng ở phía máy chủ (như trong các hàng trong bảng cơ sở dữ liệu) dưới dạng tài nguyên có thể được tạo hoặc hủy.

Cách suy nghĩ cơ bản nhất về REST là cách định dạng URL của các ứng dụng web của bạn. Ví dụ: nếu tài nguyên của bạn được gọi là "bài đăng", thì:

/posts Sẽ là cách người dùng truy cập TẤT CẢ các bài đăng, để hiển thị.

/posts/:id Sẽ là cách người dùng truy cập và xem một bài đăng riêng lẻ, được truy xuất dựa trên id duy nhất của họ.

/posts/new Sẽ là cách bạn sẽ hiển thị một hình thức để tạo một bài viết mới.

Gửi một yêu cầu POST /userssẽ là cách bạn thực sự tạo một bài đăng mới ở cấp độ cơ sở dữ liệu.

Gửi một yêu cầu PUT /users/:idsẽ là cách bạn cập nhật các thuộc tính của một bài đăng nhất định, một lần nữa được xác định bởi một id duy nhất.

Gửi một yêu cầu XÓA /users/:idlà cách bạn sẽ xóa một bài đăng nhất định, một lần nữa được xác định bởi một id duy nhất.

Theo tôi hiểu, mẫu REST chủ yếu được phổ biến (đối với các ứng dụng web) bởi khung Ruby on Rails, điều này nhấn mạnh lớn vào các tuyến RESTful. Tôi có thể sai về điều đó mặc dù.

Tôi có thể không đủ điều kiện để nói về nó, nhưng đây là cách tôi đã học nó (đặc biệt là cho sự phát triển của Rails).

Khi ai đó đề cập đến "REST api", nói chung ý nghĩa của chúng là api sử dụng các url RESTful để truy xuất dữ liệu.


2
Bạn thật may mắn, vì Rails được xây dựng theo nguyên tắc REST và nếu bạn sử dụng các công cụ Rails, mã của bạn sẽ là RESTful. Tuy nhiên, có những lập trình viên ngoài kia không hiểu về jack về REST, họ mã hóa những gì họ muốn và cuối cùng họ sử dụng 'định dạng URL' này vì nó hợp thời trang.
karatedog

8
nơi nào / người dùng đã được sử dụng trong câu trả lời này, không nên là / bài viết?
Mayuresh Srivastava

@MayureshSrivastava Quan sát rằng các ví dụ PUT có: ví dụ id và POST không có: id. Google cho phần còn lại của câu chuyện. (POST: không an toàn, không bình thường; PUT: không an toàn, bình dị)
Ajeet Ganga

38

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, JSONRDF. 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.

RESTthường được sử dụng hơn HTTP, chủ yếu là do tính đơ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. REST tuy nhiên không bị ràng buộc với bất kỳ giao thức cụ thể.

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. Chúng tôi sẽ thảo luận về đại diện không quốc tịch chi tiết hơn sau.

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 nguyên tắc trên.


15

Nó là viết tắt của Đại diện chuyển giao nhà nước và nó có thể có nhiều ý nghĩa, nhưng thông thường khi bạn nói về API và ứng dụng, bạn đang nói về REST như một cách để thực hiện các dịch vụ web hoặc nhận các chương trình để nói chuyện qua web.

REST về cơ bản là một cách giao tiếp giữa các hệ thống và thực hiện phần lớn những gì SOAP RPC được thiết kế để làm, nhưng trong khi SOAP thường tạo kết nối, xác thực và sau đó thực hiện công việc qua kết nối đó, REST hoạt động khá giống với cách mà web hoạt động . Bạn có một URL và khi bạn yêu cầu URL đó, bạn sẽ nhận lại được một cái gì đó. Đây là nơi mọi thứ bắt đầu trở nên khó hiểu bởi vì mọi người mô tả web là một ứng dụng REST lớn nhất và trong khi điều này đúng về mặt kỹ thuật thì nó không thực sự giúp giải thích nó là gì.

Tóm lại, REST cho phép bạn có được hai ứng dụng nói chuyện qua Internet bằng các công cụ tương tự như những gì trình duyệt web sử dụng. Điều này đơn giản hơn nhiều so với SOAP và rất nhiều điều REST làm, "Này, mọi thứ không cần phải quá phức tạp."

Đáng đọc:


REST là một kiến ​​trúc dựa trên các ràng buộc, SOAP là một giao thức, đó là những thứ hoàn toàn khác nhau. Tôi không thích khi mọi người nói về SOAP và REST trong cùng một khái niệm, không có gì lạ khi mọi người nhầm lẫn về nó.
Anders

@Anders - Ông nói rằng ông đang xem API REST và nghĩ rằng đó là một cách để sử dụng Dịch vụ web. Bạn có thể sử dụng REST như thế và trong khả năng đó, nó hoàn thành phần lớn những gì SOAP hoàn thành. Cũng có thể nói về web là ứng dụng RESTful lớn nhất thế giới, nhưng điều đó không thực sự giải thích bạn sử dụng API REST để làm gì.
Đánh dấu

Đây thực sự là vấn đề chính của tôi, nhìn thấy REST và SOAP trong cùng một khái niệm. Có vẻ như API chỉ là RESTful trong thiết kế.
Tù nhân

4

http://en.wikipedia.org/wiki/Repftimeation_State_Transfer

Ý tưởng cơ bản là thay vì có kết nối liên tục đến máy chủ, bạn đưa ra yêu cầu, nhận một số dữ liệu, hiển thị cho người dùng, nhưng có thể không phải tất cả, và sau đó khi người dùng thực hiện một số thứ cần thêm dữ liệu, hoặc để chuyển một số lên máy chủ, máy khách sẽ bắt đầu thay đổi trạng thái mới.


3
Có thể đó chỉ là tôi nhưng tôi thích xem câu trả lời có liên quan trên stackoverflow cùng với trích dẫn thích hợp. Chỉ cần hài hước cho tôi và giả sử wikipedia đã gặp sự cố. Liên kết của bạn làm gì tốt sau đó hmm? :)
Mã giả Monkey Rashid

1
@ Saw Saw: Không nên có trong câu trả lời của bạn?
Mã giả Monkey Rashid

Tôi chỉ nhận thấy tính năng chỉnh sửa. :)
Hack Saw

1
@karatedog: REST có thể đạt được bằng HTTP, nhưng nó có thể được thực hiện bằng nhiều phương thức truyền dữ liệu.
Hack Saw

1
Đây là giao thức HTTP mà bạn đang viết, REST là một kiến ​​trúc.
karatedog
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.