Sự khác biệt giữa HTTP và REST là gì?

Sau khi đọc rất nhiều về sự khác biệt giữa REST và SOAP, tôi có ấn tượng rằng REST chỉ là một từ khác cho HTTP. Ai đó có thể giải thích chức năng nào REST thêm vào HTTP không?

Lưu ý : Tôi không tìm kiếm sự so sánh giữa REST và SOAP.

Cập nhật : Cảm ơn câu trả lời của bạn. Bây giờ tôi đã rõ ràng rằng REST chỉ là một bộ quy tắc về cách sử dụng HTTP. Do đó tôi đã đăng một bài tiếp theo về những lợi thế của những quy ước này .

Lưu ý : Bây giờ tôi nắm được ý nghĩa của REST; như Emil Ivanov nhận xét, REST có nghĩa là sử dụng HTTP theo cách nó có nghĩa. Tuy nhiên, tôi không chắc liệu điều này có xứng đáng với một thuật ngữ của riêng mình hay không và tôi chắc chắn không có sự cường điệu xung quanh nó.

Không, REST là cách HTTP nên được sử dụng .

Ngày nay chúng ta chỉ sử dụng một chút nhỏ các phương thức của giao thức HTTP - cụ thể là GETvà POST. Cách REST để làm điều đó là sử dụng tất cả các phương thức của giao thức.

Ví dụ: REST ra lệnh sử dụng DELETEđể xóa tài liệu (có thể là tệp, trạng thái, v.v.) đằng sau một URI, trong khi đó, với HTTP, bạn sẽ sử dụng sai GEThoặc POSTtruy vấn như thế nào ...product/?delete_id=22.

HTTP là một giao thức được sử dụng để liên lạc, thường được sử dụng để giao tiếp với các tài nguyên internet hoặc bất kỳ ứng dụng nào với ứng dụng trình duyệt web.

REST có nghĩa là khái niệm chính bạn đang sử dụng trong khi thiết kế ứng dụng là Tài nguyên: đối với mỗi hành động bạn muốn thực hiện, bạn cần xác định tài nguyên mà bạn thường chỉ thực hiện thao tác CRUD, đây là một nhiệm vụ đơn giản. vì nó rất thuận tiện để sử dụng 4 động từ được sử dụng trong giao thức HTTP đối với 4 thao tác CRUD (Get for Read, POST dành cho CREATE, PUT dành cho CẬP NHẬT và XÓA là để XÓA). không giống với khái niệm cũ hơn về RPC (Cuộc gọi thủ tục từ xa), trong đó bạn có một bộ hành động bạn muốn thực hiện do kết quả của cuộc gọi của người dùng. nếu bạn nghĩ ví dụ về cách mô tả facebook như trên bài đăng, với RPC, bạn có thể tạo các dịch vụ có tên AddLikeToPost và RemoveLikeFromPost và quản lý nó cùng với tất cả các dịch vụ khác của bạn liên quan đến bài đăng FB, do đó bạn sẽ không cần phải tạo đặc biệt đối tượng cho Like. với REST, bạn sẽ có một đối tượng Like sẽ được quản lý riêng biệt với các chức năng Xóa và Tạo. Nó cũng có nghĩa là nó sẽ mô tả một thực thể riêng biệt trong db của bạn. điều đó có thể trông giống như một sự khác biệt nhỏ, nhưng làm việc như vậy thường sẽ mang lại một mã đơn giản hơn nhiều và một ứng dụng đơn giản hơn nhiều. với thiết kế đó, hầu hết logic của ứng dụng rõ ràng từ cấu trúc (mô hình) của đối tượng, không giống như RPC mà bạn thường phải thêm logic rõ ràng hơn nhiều.

thiết kế ứng dụng RESTful thường khó hơn rất nhiều vì nó yêu cầu bạn mô tả những thứ phức tạp một cách đơn giản. mô tả tất cả các chức năng chỉ sử dụng các hàm CRUD là khó khăn, nhưng sau khi thực hiện, cuộc sống của bạn sẽ đơn giản hơn rất nhiều và bạn sẽ thấy rằng bạn sẽ viết các phương thức ngắn hơn rất nhiều.

Thêm một hạn chế kiến ​​trúc REST hiện tại là không sử dụng bối cảnh phiên khi giao tiếp với máy khách (không trạng thái), nghĩa là tất cả thông tin cần để hiểu ai là khách hàng và những gì anh ta muốn được truyền qua thông điệp web. mỗi cuộc gọi đến một chức năng là tự mô tả, không có cuộc hội thoại nào trước đó với khách hàng có thể được tham chiếu trong tin nhắn. Do đó, khách hàng không thể nói với bạn "hãy cho tôi trang tiếp theo" vì bạn không có phiên để lưu trang trước đó là gì và loại trang nào bạn muốn, khách hàng sẽ phải nói "tên tôi là yuval, lấy tôi trang 2 của một bài viết cụ thể trong một diễn đàn cụ thể ". điều đó có nghĩa là sẽ có thêm một chút dữ liệu phải truyền trong giao tiếp, nhưng hãy nghĩ đến sự khác biệt giữa việc tìm lỗi được báo cáo từ chức năng "lấy tôi trang tiếp theo" để chống lại "

Tất nhiên có nhiều hơn thế, nhưng theo tôi đó là những khái niệm chính trong một muỗng cà phê.

HTTP là một giao thức ứng dụng. REST là một bộ quy tắc, khi được tuân theo, cho phép bạn xây dựng một ứng dụng phân tán có một tập các ràng buộc mong muốn cụ thể.

Nếu bạn đang tìm kiếm các ràng buộc quan trọng nhất của REST để phân biệt ứng dụng RESTful với bất kỳ ứng dụng HTTP nào, tôi sẽ nói ràng buộc "tự mô tả" và ràng buộc hypermedia (còn gọi là Hypermedia là Trạng thái ứng dụng (HATEOAS)) điều quan trọng nhất.

Ràng buộc tự mô tả yêu cầu một yêu cầu RESTful phải hoàn toàn tự mô tả trong ý định của người dùng. Điều này cho phép các trung gian (proxy và bộ nhớ cache) hành động trên tin nhắn một cách an toàn.

Ràng buộc HATEOAS là về việc biến ứng dụng của bạn thành một mạng lưới các liên kết nơi trạng thái hiện tại của khách hàng dựa trên vị trí của nó trong web đó. Đó là một khái niệm khó khăn và đòi hỏi nhiều thời gian để giải thích hơn tôi có ngay bây giờ.

Theo tôi hiểu, REST thực thi việc sử dụng các lệnh HTTP có sẵn như chúng được sử dụng.

Ví dụ, tôi có thể làm:

GET
http://example.com?method=delete&item=xxx

Nhưng với phần còn lại, tôi sẽ sử dụng phương thức yêu cầu "XÓA", loại bỏ sự cần thiết của tham số "phương thức"

DELETE
http://example.com?item=xxx

Không hẳn...

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

REST ban đầu được mô tả trong ngữ cảnh của HTTP, nhưng không giới hạn ở giao thức đó. Kiến trúc RESTful có thể dựa trên các giao thức Lớp ứng dụng khác nếu chúng đã cung cấp vốn từ vựng phong phú và thống nhất cho các ứng dụng dựa trên việc chuyển trạng thái biểu diễn có ý nghĩa. Các ứng dụng RESTful tối đa hóa việc sử dụng giao diện đã được xác định trước, được xác định rõ và các khả năng tích hợp sẵn khác được cung cấp bởi giao thức mạng đã chọn và giảm thiểu việc bổ sung các tính năng dành riêng cho ứng dụng mới.

http://www.looselycoupling.com/glossary/SOAP

(Giao thức truy cập đối tượng đơn giản) Tiêu chuẩn cho các thông điệp dịch vụ web. Dựa trên XML, SOAP định nghĩa một định dạng phong bì và các quy tắc khác nhau để mô tả nội dung của nó. Được xem (với WSDL và UDDI) là một trong ba tiêu chuẩn nền tảng của dịch vụ web, đây là giao thức ưa thích để trao đổi dịch vụ web, nhưng không có nghĩa là duy nhất; những người ủng hộ REST nói rằng nó làm tăng thêm sự phức tạp không cần thiết.

REST là một cách cụ thể để tiếp cận thiết kế các hệ thống lớn (như web).

Đó là một bộ 'quy tắc' (hoặc 'ràng buộc').

HTTP là một giao thức cố gắng tuân theo các quy tắc đó.

REST = Chuyển trạng thái đại diện

REST là một bộ quy tắc, khi được tuân theo, cho phép bạn xây dựng một ứng dụng phân tán có một tập các ràng buộc mong muốn cụ thể.

REST là một giao thức để trao đổi bất kỳ thông báo (XML, JSON, v.v.) nào có thể sử dụng HTTP để vận chuyển các thông điệp đó.

Đặc trưng:

Không có nghĩa là không có nghĩa là không nên duy trì kết nối giữa máy khách và máy chủ. Khách hàng có trách nhiệm chuyển ngữ cảnh của nó đến máy chủ và sau đó máy chủ có thể lưu trữ bối cảnh này để xử lý yêu cầu tiếp theo của khách hàng. Ví dụ: phiên được duy trì bởi máy chủ được xác định bởi mã định danh phiên được truyền bởi máy khách.

Ưu điểm của không quốc tịch:

1. Dịch vụ web có thể xử lý từng cuộc gọi phương thức riêng biệt.
2. Dịch vụ web không cần duy trì sự tương tác trước đó của khách hàng.
3. Điều này lần lượt đơn giản hóa thiết kế ứng dụng.
4. HTTP tự nó là một giao thức không trạng thái không giống như TCP và do đó, RESTful Web Services hoạt động hoàn hảo với các giao thức HTTP.

Nhược điểm của không quốc tịch:

1. Một lớp bổ sung dưới dạng tiêu đề cần phải được thêm vào mỗi yêu cầu để duy trì trạng thái của máy khách.
2. Để bảo mật, chúng tôi cần thêm thông tin tiêu đề cho mọi yêu cầu.

Các phương thức HTTP được REST hỗ trợ:

NHẬN: / chuỗi / một số chuỗi Đó là idempotent và lý tưởng nhất là trả về kết quả tương tự mỗi khi thực hiện cuộc gọi

PUT: Giống như NHẬN. Idempotent và được sử dụng để cập nhật tài nguyên.

POST: nên chứa một url và phần thân Được sử dụng để tạo tài nguyên. Nhiều cuộc gọi lý tưởng sẽ trả về các kết quả khác nhau và sẽ tạo ra nhiều sản phẩm.

XÓA: Được sử dụng để xóa tài nguyên trên máy chủ.

CÁI ĐẦU:

Phương thức CHÍNH giống hệt với GET ngoại trừ việc máy chủ KHÔNG trả về phần thân thông báo trong phản hồi. Thông tin meta chứa trong các tiêu đề HTTP để đáp ứng yêu cầu CHÍNH NÊN giống hệt với thông tin được gửi để phản hồi yêu cầu GET.

LỰA CHỌN:

Phương pháp này cho phép khách hàng xác định các tùy chọn và / hoặc yêu cầu liên quan đến tài nguyên hoặc khả năng của máy chủ mà không ngụ ý hành động tài nguyên hoặc bắt đầu truy xuất tài nguyên.

Phản hồi HTTP

Tới đây cho tất cả các câu trả lời .

Dưới đây là một vài điều quan trọng: 200 - OK 3XX - Thông tin bổ sung cần thiết từ máy khách và chuyển hướng url 400 - Yêu cầu xấu
401 - Không được phép truy cập
403 - Bị cấm
Yêu cầu hợp lệ, nhưng máy chủ đang từ chối hành động. Người dùng có thể không có các quyền cần thiết cho tài nguyên hoặc có thể cần một tài khoản nào đó.

404 - Không tìm thấy
Tài nguyên được yêu cầu không thể tìm thấy nhưng có thể có sẵn trong tương lai. Các yêu cầu tiếp theo của khách hàng được cho phép.

405 - Phương pháp không được phép Phương thức yêu cầu không được hỗ trợ cho tài nguyên được yêu cầu; ví dụ: yêu cầu GET trên biểu mẫu yêu cầu dữ liệu được trình bày qua POST hoặc yêu cầu PUT trên tài nguyên chỉ đọc.

404 - Không tìm thấy yêu cầu
500 - Lỗi máy chủ nội bộ
502 - Lỗi cổng xấu

HTTP là một giao thức truyền thông vận chuyển tin nhắn qua mạng. SOAP là một giao thức để trao đổi các thông báo dựa trên XML có thể sử dụng HTTP để vận chuyển các thông báo đó. Phần còn lại là một giao thức để trao đổi bất kỳ thông báo (XML hoặc JSON) nào có thể sử dụng HTTP để vận chuyển các thông báo đó.

HTTP is a contract, a communication protocol and REST is a concept, an architectural style có thể sử dụng HTTP, FTP hoặc các giao thức truyền thông khác nhưng được sử dụng rộng rãi với HTTP.

REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer, nó được sử dụng phổ biến nhất trong API REST chỉ vì REST was inspired by WWW (world wide web) which largely used HTTPtrước khi REST được xác định, do đó việc triển khai kiểu REST API với HTTP dễ dàng hơn.

There are three major constraints in REST (but there are more):

1. Tương tác giữa máy chủ và máy khách chỉ nên được mô tả thông qua siêu văn bản.

2.Máy chủ và máy khách nên được kết nối lỏng lẻo và không đưa ra giả định nào về nhau. Khách hàng chỉ nên biết điểm nhập tài nguyên. Dữ liệu tương tác nên được cung cấp bởi máy chủ trong phản hồi.

3.Máy chủ không nên lưu trữ bất kỳ thông tin nào về bối cảnh yêu cầu. Yêu cầu phải độc lập và bình thường (có nghĩa là nếu cùng một yêu cầu được lặp lại vô hạn, chính xác cùng một kết quả được lấy)

Và HTTP chỉ là một giao thức truyền thông (một công cụ) có thể giúp đạt được điều này.

Để biết thêm thông tin kiểm tra các liên kết sau:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

REST không nhất thiết phải gắn với HTTP . Các dịch vụ web RESTful chỉ là các dịch vụ web tuân theo kiến ​​trúc RESTful.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

Từ Bạn không biết sự khác biệt giữa HTTP và REST

Vì vậy, kiến ​​trúc REST và giao thức HTTP 1.1 độc lập với nhau, nhưng giao thức HTTP 1.1 được xây dựng để trở thành giao thức lý tưởng để tuân theo các nguyên tắc và ràng buộc của REST. Một cách để xem xét mối quan hệ giữa HTTP và REST là, REST là thiết kế và HTTP 1.1 là một triển khai của thiết kế đó.

API REST phải được điều khiển siêu văn bản

Từ blog của Roy Fielding đây là một số cách để kiểm tra xem bạn đang xây dựng API HTTP hay API REST:

Các nhà thiết kế API, vui lòng lưu ý các quy tắc sau trước khi gọi sáng tạo của bạn là API REST:

• API REST không nên phụ thuộc vào bất kỳ giao thức giao tiếp đơn lẻ nào, mặc dù ánh xạ thành công của nó đến một giao thức nhất định có thể phụ thuộc vào tính khả dụng của siêu dữ liệu, lựa chọn phương thức, v.v. Nói chung, bất kỳ yếu tố giao thức nào sử dụng URI để nhận dạng đều phải cho phép bất kỳ lược đồ URI nào được sử dụng cho mục đích nhận dạng đó. [Thất bại ở đây ngụ ý rằng nhận dạng không tách rời khỏi tương tác.]
• API REST không được chứa bất kỳ thay đổi nào đối với các giao thức truyền thông ngoài việc điền hoặc sửa các chi tiết của các bit chưa được xác định của các giao thức chuẩn, như phương thức PATCH của HTTP hoặc trường tiêu đề Liên kết. Cách giải quyết cho các triển khai bị hỏng (chẳng hạn như các trình duyệt đủ ngu ngốc để tin rằng HTML định nghĩa tập phương thức của HTTP) nên được định nghĩa riêng hoặc ít nhất là trong các phụ lục, với kỳ vọng rằng cách giải quyết cuối cùng sẽ bị lỗi thời. [Thất bại ở đây ngụ ý rằng các giao diện tài nguyên là đặc trưng cho đối tượng, không chung chung.]
• API REST nên dành hầu hết tất cả nỗ lực mô tả của nó để xác định (các) loại phương tiện được sử dụng để thể hiện tài nguyên và trạng thái ứng dụng lái xe hoặc trong việc xác định tên quan hệ mở rộng và / hoặc đánh dấu siêu văn bản cho các loại phương tiện tiêu chuẩn hiện có. Bất kỳ nỗ lực nào dành cho việc mô tả các phương pháp sử dụng cho URI quan tâm nào đều phải được xác định hoàn toàn trong phạm vi quy tắc xử lý cho loại phương tiện (và, trong hầu hết các trường hợp, đã được xác định bởi các loại phương tiện hiện có). [Thất bại ở đây ngụ ý rằng thông tin ngoài băng tần đang thúc đẩy sự tương tác thay vì siêu văn bản.]
• API REST không được xác định tên tài nguyên hoặc cấu trúc phân cấp cố định (khớp nối rõ ràng giữa máy khách và máy chủ). Máy chủ phải có quyền tự do kiểm soát không gian tên của chính họ. Thay vào đó, cho phép các máy chủ hướng dẫn khách hàng cách xây dựng các URI phù hợp, chẳng hạn như được thực hiện trong các biểu mẫu HTML và mẫu URI, bằng cách xác định các hướng dẫn đó trong các loại phương tiện và quan hệ liên kết. [Thất bại ở đây ngụ ý rằng các máy khách đang giả định cấu trúc tài nguyên do thông tin ngoài băng, chẳng hạn như tiêu chuẩn dành riêng cho miền, là định hướng dữ liệu tương đương với khớp nối chức năng của RPC].
• Một API REST không bao giờ nên có các tài nguyên được gõ gõ có ý nghĩa đối với máy khách. Các tác giả đặc tả có thể sử dụng các loại tài nguyên để mô tả việc triển khai máy chủ đằng sau giao diện, nhưng các loại đó phải không liên quan và vô hình với máy khách. Các loại duy nhất có ý nghĩa đối với khách hàng là loại phương tiện hiện tại và tên quan hệ được tiêu chuẩn hóa. [như trên]
• Nên nhập API REST mà không có kiến ​​thức trước ngoài URI (dấu trang) ban đầu và tập hợp các loại phương tiện được tiêu chuẩn hóa phù hợp với đối tượng dự định (nghĩa là, bất kỳ khách hàng nào có thể sử dụng API đều hiểu). Từ thời điểm đó, tất cả các chuyển đổi trạng thái ứng dụng phải được điều khiển bởi lựa chọn máy khách do các lựa chọn do máy chủ cung cấp có trong các biểu diễn nhận được hoặc ngụ ý bởi thao tác của người dùng đối với các biểu diễn đó. Việc chuyển đổi có thể được xác định (hoặc giới hạn bởi) kiến ​​thức của khách hàng về các loại phương tiện và cơ chế truyền thông tài nguyên, cả hai đều có thể được cải thiện nhanh chóng (ví dụ: mã theo yêu cầu). [Thất bại ở đây ngụ ý rằng thông tin ngoài băng tần đang thúc đẩy sự tương tác thay vì siêu văn bản.]