REST vs RESTful vs dịch vụ web bình thường của - có giống nhau hay không?


21

Tôi đã đọc một vài định nghĩa và thảo luận về các ứng dụng REST và / hoặc RESTful, nhưng tôi vẫn không hiểu ý nghĩa thực sự của nó.

Tôi thường làm việc với các ứng dụng tìm nạp dữ liệu qua GET hoặc gửi dữ liệu qua POST đến một số dịch vụ web (thường là tập lệnh PHP) để lấy dữ liệu từ cơ sở dữ liệu hoặc ghi vào cơ sở dữ liệu.

Bây giờ, đây có phải là một ứng dụng RESTful không? Nếu không, ứng dụng RESTful sẽ là gì? Sự khác biệt giữa khái niệm RESTful và khái niệm tôi đã làm việc cho đến nay là gì? Hãy giải thích qua một ví dụ.

Ngoài ra, ai đó đang nói về REST và ai đó về các ứng dụng RESTful. Tôi thấy rằng thuật ngữ REST đề cập đến khái niệm lý thuyết, trong khi RESTful được sử dụng khi chúng ta nói về ứng dụng cụ thể. Điều này đúng hay có sự khác biệt thực sự giữa các ứng dụng REST và RESTful?


1
Nếu bạn có thể xây dựng tất cả các Servlets của mình để lấy thông tin từ các tham số GET hoặc POST CHỈ (hoàn toàn không có gì được lưu cục bộ trước cuộc gọi), thì bạn đang áp dụng REST đúng cách. Nói cách khác, máy chủ đóng vai trò của mô hình trong MVC ở chỗ nó không được kiểm soát mà chỉ sử dụng những gì được đưa ra để thực hiện một số tác vụ. Hy vọng rằng giải thích nó tốt hơn một chút.
Neil

@Neil Tôi ở phía bên kia - ứng dụng di động. Nó là một ứng dụng khách sử dụng dịch vụ web và liên lạc với nó thông qua POST và GET. Tất cả các dịch vụ web đã được xây dựng bởi người khác và tất cả những gì tôi đã làm là sử dụng chúng. Nhưng thuật ngữ làm tôi bối rối. Vì vậy, nếu tôi đang sử dụng các kênh HTTP và các đối tượng HttpGet / HttpPost, thì tôi đang xử lý một ứng dụng RESTful, phải không?
deviDave

Không cần thiết. Không có cách nào để biết đó có phải là ứng dụng RESTful hay không nếu bạn không biết máy chủ được thực hiện như thế nào vì nó có thể vi phạm một số ràng buộc. Điều đó nói rằng, nó có thể RESTful nếu nó trả về kết quả nhất quán.
Neil

@Neil ơi, tôi nhận ngay. RESTful được thực hiện trên máy chủ. Và nếu tôi gửi một đối tượng bài đăng với một yêu cầu (không phải từng tham số riêng lẻ) thì đó có thể là một cách tiếp cận REST. Đối với một khách hàng (ứng dụng di động), không quan tâm nếu đó là REST hay không vì mã hóa là như nhau. Tôi đã hiểu đúng chưa?
deviDave

2
RESTful là cả máy chủ và máy khách, nhưng nếu bạn chỉ có thể nhìn thấy máy khách, thì bạn chỉ có thể biết liệu máy khách có tuân theo các ràng buộc hay không. Đó là tất cả những gì tôi muốn nói. Ý tôi là của REST là, nếu bạn cần đăng nhập, bạn đăng tên người dùng và mật khẩu. Máy chủ xác nhận đăng nhập và lưu khóa băm của người dùng trên cơ sở dữ liệu và trả về nó. Bây giờ bất cứ khi nào bạn cần thực hiện một thao tác yêu cầu đăng nhập, bạn luôn vượt qua khóa băm của người dùng. Máy chủ "quên" rằng nó đã đăng nhập bạn, nhưng sử dụng hàm băm của người dùng để xác thực trạng thái đăng nhập của bạn. Nếu không phải là RESTful, máy chủ sẽ nhớ bạn đã đăng nhập. Hiểu sự khác biệt?
Neil

Câu trả lời:


13

Các thuộc tính chính của ứng dụng RESTful là: Tất cả giao tiếp đều thông qua http GET, POST, PUT, DELETE tất cả các mục được xử lý thông qua một URL tiêu chuẩn của biểu mẫuhttp://your.site.com/salesapp/salesperson/0000001/details tức là chỉ một URL thuần túy không có tham số, v.v. URL xác định điều GET , POST, PUT, DELETE xác định những gì bạn muốn làm với nó.

Lý do chính để làm điều này là bạn tự động có một dịch vụ phi trạng thái có thể được cân bằng tải, thất bại, v.v.

Sự đơn giản tuyệt đối của lược đồ tạo ra một giao diện rất sạch sẽ, hoàn toàn tách rời máy khách khỏi bất kỳ triển khai back-end cụ thể nào.


Ồ, cho đến nay tôi chưa sử dụng PUT hoặc DELETE (các ứng dụng di động thường chỉ NHẬN và POST), nhưng điều này thực sự giống như những gì tôi đã làm và đang làm vào lúc này. Chỉ là khách hàng không sử dụng thuật ngữ REST *, mà là "dịch vụ web" và "tập lệnh php"
deviDave

2
James, bạn có thể giải thích tại sao cần tránh các tham số truy vấn không? Ví dụ: làm thế nào để tôi thể hiện rằng tôi muốn các tài nguyên được lọc theo một cách cụ thể mà không đưa ra một hệ thống phân cấp sai?
Gary Rowe

3
@GaryRowe: URL (không có tham số) xác định tài nguyên bạn muốn thao tác. Bạn vẫn có thể có các tham số nhưng chúng không được sử dụng để xác định tài nguyên. Ví dụ một GET trên một thư mục (một URL kết thúc bằng /) sẽ trả về một danh sách các tài nguyên trong thư mục. Một tham số trên URL có thể được sử dụng để chỉ định bộ lọc hoặc thứ tự sắp xếp hoặc một cái gì đó tương tự.
Martin York

1
Cảm ơn, Loki. James có thể muốn chỉnh sửa câu trả lời của mình để phản ánh rằng vì có vẻ như anh ta không cho phép các tham số truy vấn được sử dụng trong bất kỳ trường hợp nào có thể gây hiểu nhầm. Trên thực tế, có một quan sát thú vị rằng danh sách các tài nguyên trong một thư mục tự nó là một tài nguyên thể hiện khái niệm đó.
Gary Rowe

REST không yêu cầu ứng dụng phải dựa trên URL, cũng không yêu cầu bạn phải có các động từ như GET, POST, DELETE, v.v. Tuy nhiên, đối với một ứng dụng Web, URL là tùy chọn duy nhất và các động từ đã nói ở trên.
Nawaz

6

REST là viết tắt của Chuyển giao Nhà nước Đại diện. Nếu phần mềm của bạn tuân thủ các ràng buộc REST thì nó được coi là RESTful.

Phải, bây giờ tôi đã xấu hổ tách khỏi Wikipedia, điều này thực sự có ý nghĩa gì? Điều này có nghĩa là sử dụng các lệnh HTTP sẵn có như GET, POST, PUT, DELETE và một vài thứ hiếm hơn khác để liên lạc qua lại giữa máy khách và máy chủ.

Những gì bạn đang làm nghe giống như một ứng dụng RESTFul. Tuy nhiên, có một sự khác biệt lớn giữa các dịch vụ web RESTFul được thiết kế tốt và chất đống. Ví dụ, mã PHP ở đầu kia của GET có thể thực thi thay đổi trạng thái, điều này sẽ bị coi là sai vì GET được xem là thao tác chỉ đọc. Có sự khác biệt tinh tế giữa cách sử dụng POST (mới) và PUT (thay thế).

Bài viết Wikipedia về điều này thực sự tốt, vì vậy tôi sẽ dừng ở đây.


Cho đến nay, tôi đã sử dụng GET (HttpGet) để tìm nạp nội dung và POST (HttpPost) để nhập / thay đổi nội dung của cơ sở dữ liệu. Tôi đã gửi cái này dưới dạng tham số cho tập lệnh httpPost và PHP trên máy chủ web đã chuyển đổi các tham số này thành mã SQL. Đây có phải là một ứng dụng RESTful? Tôi quan tâm đến một khái niệm, không phải là kịch bản PHP đã được thực hiện tốt như thế nào. Tôi đã không làm điều đó.
deviDave

2
Tôi sẽ điều tra việc sử dụng PUT trong trường hợp bạn thay thế nội dung, REST thành ngữ hơn là luôn sử dụng POST.
Martijn Verburg

Có, trong trường hợp như vậy tôi sẽ sử dụng PUT.
deviDave

+1 để lưu ý rằng GET phải được triển khai chính xác (nghĩa là nó không hoạt động). Như một lỗi cơ bản trong những ngày đầu.
Gary Rowe

@deviDave Bạn cũng có thể muốn xem xét PATCH được thiết kế để cập nhật một phần của tài nguyên. Như Martin chỉ ra đúng PUT là để thay thế toàn bộ tài nguyên.
Gary Rowe

4

Trước khi đi xa hơn, câu hỏi liên quan này có thể giúp bạn

Sự khác biệt giữa REST và RESTful chỉ đơn giản là ngữ nghĩa. REST là một kiểu kiến ​​trúc được áp dụng cho mối quan hệ máy khách-máy chủ. RESTful chỉ đơn giản là một cách để nói với khách hàng của bạn rằng bạn sử dụng REST.

Nhiều ứng dụng web tuyên bố là RESTful, nhưng thực tế chỉ tuân thủ một phần với các ràng buộc REST (vì Martijn Verburg cũng đã tham chiếu trong câu trả lời của mình). Tôi sẽ chỉ liệt kê chúng ở đây nhưng tôi rất mong bạn đọc bài viết:

  • Máy chủ của khách hàng
  • Có thể lưu trữ
  • Hệ thống lớp
  • Mã theo yêu cầu (tùy chọn)

Vì bạn đề cập rằng bạn làm việc ở phía máy khách, có thể hữu ích để xem kiến ​​trúc REST sẽ cung cấp và mong đợi gì từ bạn như một máy khách kết nối. Mặc dù REST không phải là HTTP nhưng cho đến nay, giao thức phổ biến nhất hỗ trợ REST là gì vì vậy tôi sẽ đóng khung ví dụ của mình xung quanh đó.

Khách hàng của bạn sẽ được yêu cầu:

  • sử dụng các động từ HTTP (ví dụ: GET, POST, PUT, DELETE, OPTION, PATCH) để thực hiện các hoạt động liên quan
  • cung cấp các tiêu đề Chấp nhận và hiểu các tiêu đề Kiểu Nội dung (ví dụ: bạn nhận được một số XML bạn chưa từng thấy trước đây nhưng bạn có thể sử dụng XSD được tham chiếu để tạo mô hình miền phía máy khách để trình bày cho người dùng của mình)
  • theo các liên kết được cung cấp trong Loại nội dung mà bạn hiểu (ví dụ: giúp người dùng hoặc ứng dụng của bạn suy luận rằng <link rel="pay" href="http://example.org/orders(1)/payment">trong HTML thể hiện sự chuyển đổi trạng thái để tạo tài nguyên thanh toán thông qua POST với phần thân có chứa một số XML biểu thị chi tiết thanh toán như số thẻ tín dụng , số lượng và như vậy)
  • phản ứng chính xác với phạm vi rộng của mã trạng thái HTTP

Nếu nó làm như trên thì có thể được coi là một ứng dụng khách REST, bạn có thể muốn gọi nó là "ứng dụng RESTful" nhưng điều đó có nghĩa là bạn đang sử dụng REST ở phía máy khách không chính xác để tránh hạn


3

RESTful có nghĩa là giao diện là một tập hợp các đối tượng, có thể được đọc và cập nhật (và có thể bị xóa). Đó là không có truy vấn đa tham số (chỉ tham số là đối tượng bạn muốn đọc) và chỉ có một loại hoạt động thay đổi bất cứ điều gì trên máy chủ, tải lên trạng thái mới.

Những hạn chế này đảm bảo rằng tất cả các yêu cầu đều bình thường (gửi chúng nhiều lần không có bất kỳ ảnh hưởng nào thêm đến việc gửi chúng một lần). Điều này rất quan trọng, vì mạng có thể bị lỗi bất cứ lúc nào và không cung cấp bất kỳ yêu cầu hoặc phản hồi nào và với các yêu cầu tạm thời, bạn chỉ cần gửi lại và không phải thực hiện khôi phục phức tạp.


Upvote cho đoạn 1. Thật súc tích. Cảm ơn!
deviDave

Một điều nữa, để xem tôi đã làm đúng chưa. Nếu tôi (ứng dụng của tôi) là khách hàng của dịch vụ REST, thì tôi với tư cách là khách hàng không biết liệu dịch vụ có RESTful hay không vì mã hóa của tôi luôn giống nhau (httpget, omepost, v.v.)? Nguyên tắc này chỉ quan trọng đối với chủ sở hữu của một tập lệnh / ứng dụng máy chủ?
deviDave

REST là một hướng dẫn để thiết kế ngữ nghĩa của giao diện. Công nghệ cơ bản là HTTP cho dù giao diện có RESTful hay không (nhưng các lớp khác như XML-RPC hoặc SOAP không liên quan đến giao diện RESTful), vì vậy bạn luôn sử dụng cùng một httpget, omepppost, v.v. Nhưng bạn xử lý các lỗi mạng khác nhau.
Jan Hudec

để thêm, SMTP là một giao diện RESTful, mặc dù nó sử dụng các động từ khác nhau từ GET, PUT, v.v. và một giao thức cơ bản khác nhau, khái niệm này giống nhau - bạn gửi các lệnh dựa trên động từ idempotent đến máy chủ.
gbjbaanb

Không phải tất cả các yêu cầu REST là idempotent. Ví dụ: phát hành POST nhiều lần sẽ dẫn đến rất nhiều tài nguyên mới.
Gary Rowe
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.