Kiến trúc REST chính xác là gì và nó được triển khai như thế nào trong Rails?

Question

Đây là những gì tôi nghĩ về kiến ​​trúc REST.

Đối với mọi tài nguyên, có một URI duy nhất.

Chúng ta có thể thao tác đối tượng đó bằng cách sử dụng các hành động URI và HTTP của nó [POST, GET, PUT và DELETE]. Yêu cầu HTTP chuyển biểu diễn trạng thái của đối tượng đó.

Trong tất cả các văn bản tôi đã đọc, REST được giải thích một cách kỳ lạ và khó hiểu.

Một điều nữa, thực hiện RESTFUL trong đường ray tạo ra các url khác nhau cho các mục đích khác nhau. Giống như/đội -> cho phương pháp 'chỉ mục' .../đội/mới -> cho phương pháp 'mới' và v.v. Không phải điều này chuyển động khỏi phần còn lại, trong đó xác định rằng mỗi tài nguyên có một URI duy nhất ???

Answer 1

Tôi nghĩ rằng sự hiểu biết của bạn về REST khá tốt. Nó không cần phải phức tạp hơn nó nên. Ngoài ra @ Surya phác thảo một số điểm rất tốt.

Cách Rails bản đồ các phương thức HTTP để điều khiển các phương pháp là:

GET => show 
PUT => update 
POST => create 
DELETE => destroy 

Hai nguồn/phương pháp khác mà ray cung cấp cụ thể là:

resource/new => new 
resource/edit => edit 

có nhiều khả năng không nguồn lực cho tất cả các mục đích thực tế nhưng là cần thiết để xây dựng trang web và ứng dụng. Nếu khách hàng có kiến ​​thức đầy đủ về tài nguyên, thì điều này sẽ không cần thiết. Khách hàng chỉ có thể thực hiện các cuộc gọi POST và PUT với thông tin tài nguyên và tạo hoặc cập nhật tài nguyên nếu cần. Nhưng vì người dùng không được dự kiến ​​sẽ biết được các ins and outs của một tài nguyên, họ cần một giao diện dễ dàng hơn để làm việc với việc tạo hoặc cập nhật.

Nếu tất cả người dùng đã nhận thức đầy đủ về tài nguyên và đủ khéo léo với dòng lệnh, chúng tôi thậm chí sẽ không cần HTML. Họ chỉ có thể curl trong tương tác của họ với các tài nguyên đó :)

index chỉ giúp làm việc dễ dàng hơn với bộ sưu tập. Nó vẫn là một tài nguyên được xác định rõ và có một biểu diễn duy nhất, ví dụ: /books. Làm thế nào nó được xử lý trên các mã phía máy chủ không làm cho nó RESTless (Tôi chỉ làm điều đó lên, nhưng tuyệt vời của nó).

Answer 2

Như bạn có thể nhận thấy có 4 hành động HTTP nhưng các hoạt động CRUD cơ bản trong một ứng dụng web điển hình yêu cầu 7 hành động khác nhau. Một số không thực sự làm bất cứ điều gì (như /new và :id/edit) và do đó là loại song song với kiến ​​trúc REST. Ngoài ra các hành động chỉ mục không hành động trên tài nguyên mà là trên một tập hợp các nguồn lực (do đó cũng là một url duy nhất).

Vì vậy, các cơ sở 4 hành động HTTP bản đồ tới một tài nguyên như thế này:

• GET bản đồ để hiển thị ->get /teams/:id
• bản đồ PUT để cập nhật ->put /teams/:id
• DELETE bản đồ để tiêu diệt ->delete /teams/:id
• BÀI ĐĂNG là một ngoại lệ, vì tài nguyên chưa tồn tại, do đó, nó ánh xạ tới cơ sở /teams

Vì vậy, để tóm tắt: mỗi tài nguyên có url duy nhất của riêng nó, cộng với đường ray xác định một vài url bổ sung cho giao diện người dùng và mục đích thu thập.

Answer 3

Tôi muốn bắt đầu với chapter 5 của luận án của Roy Fielding. Có một vài nguyên tắc cơ bản:

• Tài nguyên: Một tài nguyên có thể thường là thứ bạn tiếp xúc với thế giới bên ngoài như một phần của dịch vụ. Điểm nhấn là xác định các tài nguyên (ví dụ: Sách, Danh sách người dùng, Tính toánDistance)
• URI: Cung cấp cho mọi tài nguyên một số nhận dạng (ví dụ: example.com/books/7654)
• Giao diện đồng nhất: Sử dụng các phương thức chuẩn như GET, PUT . POST, DELETE, HEAD, OPTIONS
• Đại diện: Một tài nguyên có thể có nhiều biểu diễn. Ví dụ, một GET trên một cuốn sách có thể trả lại một tệp PDF nội dung của cuốn sách đó, một HTML của nội dung và cho rằng vấn đề ngay cả một GIF với bìa sách và vân vân. Một đại diện về cơ bản là một tập hợp tất cả các dữ liệu và đánh dấu.
• Hypermedia: Cái này, theo ý kiến ​​của tôi, là một nguyên tắc rất quan trọng. Việc thực hiện nguyên tắc này đưa ứng dụng của bạn vượt xa các định nghĩa giống như CRUD thông thường mà kiểu REST được đóng gói. HATEOAS là từ viết tắt của Hypermedia là công cụ của trạng thái ứng dụng. Khi bạn nhấp vào liên kết hoặc gửi biểu mẫu, bạn đang thay đổi trạng thái của ứng dụng, điều đó xảy ra thông qua siêu liên kết (hoặc hypermedia). Có rất ít sự kết nối giữa máy chủ và máy khách. Một khách hàng điều hướng thông qua ứng dụng thông qua các liên kết được cung cấp bởi máy chủ. (có rất nhiều cuộc thảo luận trong thế giới blog trên priniciple này ...) [Ngoài ra, hãy xem Restfulie]

Gần đây tôi có answered a question tài nguyên tốt để tìm hiểu REST, có thể hữu ích.

Tôi không quen thuộc với Rails, do đó không giải quyết được phần đó của câu hỏi.

Answer 4

Giống như/nhóm -> cho phương pháp 'chỉ mục' ... /teams/new -> cho phương pháp 'mới' và do đó bật. Không phải điều này chuyển động khỏi phần còn lại, xác định rằng mỗi tài nguyên có một URI duy nhất ???

Không có điều này không di chuyển khỏi REST, vì theo như REST liên quan /teams và /teams/new là hai tài nguyên khác nhau.

Answer 5

Đây là phác thảo cơ bản về REST của tôi. Tôi đã cố gắng chứng minh tư duy đằng sau mỗi thành phần trong một kiến ​​trúc RESTful để hiểu được khái niệm trực quan hơn. Hy vọng điều này sẽ giúp làm sáng tỏ REST cho một số người!

REST (Chuyển giao trạng thái đại diện) là một kiến ​​trúc thiết kế mô tả cách các tài nguyên được nối mạng (tức là các nút chia sẻ thông tin) được thiết kế và giải quyết. Nói chung, một kiến ​​trúc RESTful làm cho nó để máy khách (máy yêu cầu) và máy chủ (máy trả lời) có thể yêu cầu đọc, viết và cập nhật dữ liệu mà không cần máy khách biết máy chủ hoạt động như thế nào và máy chủ có thể vượt qua nó trở lại mà không cần biết bất cứ điều gì về khách hàng. Được rồi, tuyệt ... nhưng làm thế nào để chúng tôi làm điều này trong thực tế?

• Yêu cầu rõ ràng nhất là cần phải có ngôn ngữ chung để sắp xếp máy chủ cho khách hàng biết yêu cầu và máy chủ phản hồi.

• Nhưng để tìm bất kỳ tài nguyên cụ thể nào và sau đó báo cho khách hàng biết nguồn tài nguyên đó đang sống ở đâu, cần phải có một cách phổ biến để chỉ tài nguyên. Đây là nơi các Mã định danh tài nguyên phổ dụng (URI) đi vào; chúng về cơ bản là địa chỉ duy nhất để tìm các tài nguyên.

Nhưng kiến ​​trúc REST không kết thúc ở đó! Trong khi ở trên đáp ứng nhu cầu cơ bản của những gì chúng ta muốn, chúng ta cũng muốn có một kiến ​​trúc hỗ trợ lưu lượng lớn vì bất kỳ máy chủ nào cũng thường xử lý các phản hồi từ một số máy khách. Do đó, chúng tôi không muốn áp đảo máy chủ bằng cách nhớ thông tin về các yêu cầu trước đó.

• Do đó, chúng tôi áp đặt những hạn chế mà mỗi cặp yêu cầu-phản ứng giữa máy khách và máy chủ là độc lập, có nghĩa là máy chủ không phải nhớ bất cứ điều gì về các yêu cầu trước đó (tình trạng trước đó của client-server tương tác) để trả lời yêu cầu mới. Điều này có nghĩa là chúng tôi muốn các tương tác của chúng tôi là không trạng thái.

• Để giảm bớt căng thẳng trên máy chủ của chúng tôi từ việc thực hiện lại các tính toán đã được thực hiện gần đây cho một ứng dụng khách định, REST cũng cho phép lưu vào bộ nhớ đệm. Về cơ bản, bộ đệm ẩn có nghĩa là chụp nhanh phản hồi ban đầu được cung cấp cho máy khách. Nếu máy khách thực hiện yêu cầu tương tự một lần nữa, máy chủ có thể cung cấp máy khách với ảnh chụp nhanh hơn là làm lại tất cả các tính toán cần thiết để tạo ra phản hồi ban đầu. Tuy nhiên, vì nó là ảnh chụp nhanh, nếu ảnh chụp chưa hết hạn - máy chủ đặt thời gian hết hạn - và phản hồi đã được cập nhật kể từ bộ đệm ban đầu (tức là yêu cầu sẽ trả lời khác với phản hồi được lưu trong bộ nhớ cache) , khách hàng sẽ không thấy các bản cập nhật cho đến khi bộ nhớ cache hết hạn (hoặc bộ nhớ cache bị xóa) và phản hồi được hiển thị lại từ đầu.

• Điều cuối cùng bạn thường thấy ở đây về kiến ​​trúc RESTful là chúng được xếp lớp. Chúng tôi đã thực sự đã thảo luận hoàn toàn về yêu cầu này trong cuộc thảo luận của chúng tôi về sự tương tác giữa máy khách và máy chủ. Về cơ bản, điều này có nghĩa là mỗi lớp trong hệ thống của chúng ta chỉ tương tác với các lớp lân cận. Vì vậy, trong phần thảo luận của chúng tôi, lớp máy khách tương tác với lớp máy chủ của chúng tôi (và ngược lại), nhưng có thể có các lớp máy chủ khác giúp máy chủ chính xử lý yêu cầu mà máy khách không liên lạc trực tiếp. Thay vào đó, máy chủ chuyển yêu cầu khi cần thiết.

Bây giờ, nếu tất cả điều này nghe có vẻ quen thuộc, thì tuyệt vời. Giao thức truyền siêu văn bản (HTTP), định nghĩa giao thức truyền thông qua World Wide Web là việc thực hiện khái niệm trừu tượng của kiến ​​trúc RESTful (hoặc một thể hiện của lớp REST nếu bạn là một người cuồng tín OOP như tôi). Trong việc thực hiện REST này, máy khách và máy chủ tương tác thông qua GET, POST, PUT, DELETE, vv, là một phần của ngôn ngữ phổ quát và các tài nguyên có thể được chỉ ra bằng cách sử dụng các URL.