Chà, có rất nhiều cách để học cách xây dựng một ứng dụng web RESTful và không, không có cách nào đúng cả. RESTful không phải là một tiêu chuẩn nhưng nó sử dụng một bộ các tiêu chuẩn (HTTP, URI, Mime Type, ...).
Bắt đầu với điều này: Làm thế nào tôi giải thích REST cho vợ tôi
Sau đó, tiến hành việc này: Sổ tay dịch vụ web RESTful
Và sau đó dồn toàn bộ nỗ lực của bạn để phát triển các ứng dụng web vì cách tốt nhất để học là làm thí nghiệm và bạn có thể học được rất nhiều từ những sai lầm của mình;)
Đừng lo lắng nếu các ứng dụng web đầu tiên của bạn sẽ không hoàn toàn RESTful: bạn sẽ tìm ra cách để làm điều đó!
Vì vậy, trích dẫn Obi-Wan Kenobi, "có thể lực lượng sẽ ở bên bạn!" ;)
CHỈNH SỬA
Ok, hãy để tôi được cụ thể hơn.
Bạn muốn làm một số ứng dụng web RESTful, phải không? Vâng, như tôi đã nói có nhiều cách để làm điều đó nhưng đây là hướng dẫn chính.
Định nghĩa
REST (Chuyển giao trạng thái đại diện) là kiểu kiến trúc phần mềm cho hệ thống phân tán (như WWW). Nó không phải là một tiêu chuẩn nhưng nó sử dụng một bộ các tiêu chuẩn: HTTP, AJAX, HTML, URI, Mime Type, v.v. Chúng ta đang nói về việc đại diện cho một tài nguyên, chứ không phải về bản thân một tài nguyên. Lấy từ 'Cách tôi giải thích REST cho vợ tôi':
Vợ : Một trang web là một tài nguyên?
Ryan : Loại. Một trang web là một đại diện của một tài nguyên. Tài nguyên chỉ là khái niệm.
Những ràng buộc của kiến trúc
- Máy khách-Máy chủ : máy khách và máy chủ được phân tách bằng Giao diện thống nhất (được mô tả bên dưới).
- Không trạng thái : giao tiếp giữa máy chủ và máy khách được thực hiện mà không lưu trạng thái máy khách cụ thể trên máy chủ.
- Bộ nhớ cache: máy khách có thể có bộ đệm phản hồi của các yêu cầu đã được thực hiện.
- Hệ thống phân lớp : khách hàng không biết liệu nó được kết nối trực tiếp với máy chủ cuối hay nếu giao tiếp được thực hiện thông qua các trung gian.
Giao diện thống nhất
- Nhận dạng tài nguyên: mỗi tài nguyên phải được xác định bởi một URI.
- Giao thức : để có được trong máy khách và máy chủ giao tiếp, một giao thức phải được thực hiện trước đó. Mỗi yêu cầu có thể có Loại MIME đúng (application / xml, text / html, application / rdf + xml, v.v.), các tiêu đề đúng và phương thức HTTP đúng (xem mô tả CRUD bên dưới).
CRUD
Ok, chúng tôi thấy rằng để xác định tài nguyên, chúng tôi có thể sử dụng URI, nhưng chúng tôi cần một số thứ khác cho các hành động (thêm, sửa đổi, xóa, v.v.): rất hoan nghênh CRUD (Tạo, Đọc, Cập nhật và Xóa).
- Tạo { HTTP: POST } { SQL: INSERT } => tạo tài nguyên mới
- Đọc { HTTP: GET } { SQL: SELECT } => lấy tài nguyên
- Cập nhật { HTTP: PUT } { SQL: UPDATE } => sửa đổi tài nguyên
- Xóa { HTTP: DELETE } { SQL: DELETE } => xóa tài nguyên
Bây giờ, liên quan đến PUT và DELETE, một số vấn đề công nghệ có thể xuất hiện (bạn sẽ giải quyết chúng bằng dạng HTML): thường các nhà phát triển bỏ qua vấn đề này bằng cách sử dụng POST cho mỗi yêu cầu 'PUT' và 'DELETE'. Chính thức, bạn phải sử dụng PUT và XÓA. Nhân tiện, làm những gì bạn muốn. Kinh nghiệm của tôi thúc đẩy tôi sử dụng POST và GET mỗi lần.
--- Phần tiếp theo nên được sử dụng nhưng nó không phải là trái phiếu của REST: nó liên quan đến Dữ liệu được liên kết ---
URI
Tóm tắt URI từ các chi tiết kỹ thuật! Nói lời tạm biệt với URI như sau:
http://www.example.com/index.php?query=search&id=9823&date=08272012
Thiết kế lại URI! Lấy liên kết ở trên và thay đổi nó như sau:
http://www.example.com/search/2012/08/27/9823
Điều đó tốt hơn nhiều hả? Nó có thể được thực hiện bởi:
Một điều khác: sử dụng URI khác nhau để thể hiện các tài nguyên khác nhau:
Hãy chú ý : about.html và about.rdf không phải là tệp! Chúng có thể là kết quả của một chuyển đổi XSLT!
Đàm phán nội dung
Nếu bạn đã đạt đến điểm này, xin chúc mừng! Có lẽ, bạn đã sẵn sàng để có được các khái niệm trừu tượng hơn bởi vì chúng tôi đang nhập các chi tiết kỹ thuật của Semantic Web;) Vâng, khi khách hàng của bạn muốn có một tài nguyên, nó thường đưa ra yêu cầu sau:
GET http://www.example.com/about
Accept: application/rdf+xml
Nhưng máy chủ sẽ không phản hồi với about.rdf vì nó có URI khác ( http://www.example.com/about.rdf ). Vì vậy, chúng ta hãy nhìn vào mẫu 303 ! Máy chủ sẽ trả về điều này:
303 See Other
Location: http://www.example.com/about.rdf
Và khách hàng sẽ theo liên kết được trả lại như sau:
GET http://www.example.com/about.rdf
Accept: application/rdf+xml
Cuối cùng, máy chủ sẽ trả về tài nguyên được yêu cầu:
200 OK
about.rdf
Đừng lo lắng: ứng dụng khách của bạn sẽ không làm gì cả! Mẫu 303 phải được thực hiện bởi ứng dụng máy chủ và trình duyệt của bạn sẽ làm phần còn lại;)
Phần kết luận
Thông thường lý thuyết là xa, xa thực tiễn. Vâng, bây giờ bạn đã biết cách thiết kế và phát triển ứng dụng RESTful nhưng hướng dẫn ở trên chỉ là một gợi ý. Bạn sẽ tìm thấy cách tốt nhất để xây dựng các ứng dụng web và có lẽ nó sẽ không giống như lý thuyết muốn. Đừng cho nó chết tiệt: D!
Tài liệu tham khảo
Dịch vụ web RESTful, Tyagi tương tự
API REST phải được điều khiển siêu văn bản, Roy Thomas Fielding
Dịch vụ web RESTful: Những điều cơ bản, Alex Rodriguez
Quy trình làm việc của Webber REST