Cách thích hợp để làm REST là gì?


36

Ngày nay mọi người đều làm SOA , ngay cả khi một số người không thực sự hiểu tất cả những gì về. Vì vậy, họ làm sai. Sử dụng điều đó như một sự tương tự tôi biết REST là gì (hoặc ít nhất là tôi nghĩ tôi làm) và muốn thực hiện một số điều đó. Nhưng tôi muốn làm đúng.

Vì vậy, câu hỏi của tôi là cách thích hợp để làm REST là gì?


1
Wiki thẻ Stack Overflow 'rest' dường như gần với tài nguyên chính trong bối cảnh mạng Stack Exchange
gnat

17
Tôi chỉ nhắm mắt một lúc ... có thể đi xe đạp và sau đó nằm xuống.
Edward Strange

Không phải REST về cơ bản chỉ sử dụng một url như mydomain.com/accounts và động từ HTTP để gọi một hoạt động? Trường hợp động từ chỉ ra bạn có muốn lấy, tạo, cập nhật hoặc xóa dữ liệu không? Khi tôi nghĩ REST đó là những gì tôi nghĩ.
Người đàn ông Muffin

2
@Nick, đó là việc giải thích phổ biến nhất, các 'thật' là khó khăn hơn rất nhiều để grok, và (như xa như tôi có thể nói) khó khăn hơn rất nhiều để tìm thực sự thực hiện bất cứ nơi nào ... (xem câu trả lời Wilk)
Benjol

3
@Nick sự hiểu biết của bạn không phải là REST, đó là RPC qua HTTP .

Câu trả lời:


30

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


1
Bạn có thể xem xét thêm liên kết này , đây là hướng dẫn đầy đủ nhất mà tôi đã gặp.
Stewol

Tôi đã thấy PUT và POST được sử dụng với ý nghĩa của chúng được hoán đổi (liên quan đến câu trả lời của bạn): POST -> tạo, PUT -> cập nhật. Bất kỳ ý tưởng nào có nghĩa là được sử dụng rộng rãi hơn?
Andres F.

@Andres F.: Jcalcote.wordpress.com/2008/10/16/ từ nói: Tạo = PUT nếu bạn đang gửi toàn bộ nội dung của tài nguyên được chỉ định (URL). Tạo = POST nếu bạn đang gửi lệnh đến máy chủ để tạo cấp dưới của tài nguyên đã chỉ định, sử dụng một số thuật toán phía máy chủ. Cập nhật = PUT nếu bạn đang cập nhật toàn bộ nội dung của tài nguyên đã chỉ định. Cập nhật = POST nếu bạn đang yêu cầu máy chủ cập nhật một hoặc nhiều cấp dưới của tài nguyên đã chỉ định.
Wilk

@Benjol: Tôi sẽ chỉnh sửa với đề xuất của bạn;) Cảm ơn!
Wilk

1
@Wilk Một số điều cần xem xét! Có lẽ tại sao không ai có quyền này: P
Andres F.

5

một cuốn sách kinh thánh REST hoặc một cái gì đó ....

Không có cuốn sách kinh thánh cần thiết; Tôi có cùng một câu hỏi chính xác và học mọi thứ tôi cần hoặc muốn biết về REST bằng cách đọc ba bài viết sau:

  1. Giới thiệu về người mới bắt đầu về HTTP và REST từ Net Tuts +
  2. Các dịch vụ Web RESTful: Những điều cơ bản từ IBM DB2
  3. HTTP RESTful trong thực tế từ InfoQ

Nhưng tôi muốn làm đúng.

Như bạn sẽ đọc trong các bài viết ở trên, điều quan trọng là nghĩ về các phần có thể truy cập của ứng dụng của bạn là "tài nguyên" có thể được tạo, truy xuất, cập nhật hoặc xóa bằng cách sử dụng các "động từ" HTTP hiện có: GET, PUT, POST , XÓA BỎ.

Ngoài ra, hãy biết sự khác biệt giữa PUT và POST và khi nào nên sử dụng chúng. NHẬN, PUT, và XÓA nên là các giao dịch tạm thời, POST không nên.

Ngoài ra, sử dụng đúng mã trạng thái HTTP khi liên lạc lại với máy khách.

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.