Để tôi nghỉ ngơi một chút. Bắt được anh ở đó.
Điều tôi muốn nói là để tôi cho các bạn
một cái nhìn tổng quan ngắn gọn về chuyển giao nhà nước đại diện.
REST chính xác là gì?
Làm thế nào để chúng ta sử dụng nó trong ứng dụng React của chúng tôi,
và làm thế nào để chúng ta sử dụng nó để giao tiếp với máy chủ?
Làm thế nào để một máy chủ hỗ trợ REST API
và làm thế nào để chúng tôi truy cập API REST từ ứng dụng React của chúng tôi?
Chúng ta hãy nói về điều đó một chút nữa trong bài học này.
Tôi chắc chắn bạn đã nghe thuật ngữ dịch vụ web được đề cập trong thế giới CNTT rất thường xuyên.
Chính xác các dịch vụ web là gì?
Dịch vụ Web là một cách thiết kế các hệ thống để hỗ trợ khả năng tương tác
giữa các hệ thống được kết nối qua một mạng như internet như chúng ta thấy ngày nay.
Đây là những gì chúng tôi gọi là một kiến trúc định hướng dịch vụ.
Bây giờ, điều này có nghĩa là bạn cung cấp
một cách chuẩn hóa cho hai máy được kết nối với internet để có thể
giao tiếp với nhau ở
cấp lớp ứng dụng cho các ứng dụng dựa trên web sử dụng các chuẩn mở.
Bây giờ, tôi đã sử dụng rất nhiều thuật ngữ ở đó.
Chúng ta hãy cố gắng phá vỡ chúng và hiểu
một chút về từng điều đó trong bài giảng này.
Hai cách tiếp cận phổ biến được sử dụng để hỗ trợ các dịch vụ web là SOAP.
Các dịch vụ web dựa trên giao thức truy cập đối tượng đơn giản sử dụng
ngôn ngữ mô tả dịch vụ web
để xác định cách hai điểm cuối giao tiếp với nhau.
Thông thường SOAP dựa trên việc sử dụng XML làm
định dạng cho các thư được trao đổi giữa hai điểm cuối.
Chuyển trạng thái đại diện hay REST cũng sử dụng
các tiêu chuẩn web, nhưng việc trao đổi dữ liệu giữa hai điểm cuối có thể là XML hoặc
ngày càng sử dụng JSON làm định dạng.
Cách tương tác REST đơn giản hơn so với SOAP và do đó,
REST đã tìm thấy triển khai rộng hơn rất nhiều trong thế giới dịch vụ web.
Thông thường, giao tiếp client-server được
tạo điều kiện bằng cách sử dụng REST nơi máy chủ hỗ trợ một REST API và máy
khách sau đó có thể gọi các điểm cuối REST API
để có được thông tin hoặc tải thông tin lên máy chủ.
Một lần nữa, tôi đã đề cập từ gọi các điểm cuối REST API,
vì vậy đây là một vài thuật ngữ mà tôi đã sử dụng.
Hãy làm rõ một số trong số này trong vài trang trình bày tiếp theo.
Chuyển giao trạng thái đại diện là một phong cách kiến trúc phần mềm
được thiết kế đặc biệt cho các siêu phương tiện truyền thông phân tán qua World Wide Web.
Điều này lần đầu tiên được Roy Fielding giới thiệu trong luận án tiến sĩ của ông.
Đây là một trong những luận án tiến sĩ
thực sự tạo ra một thứ gì đó hữu ích cho thế giới.
Vì vậy, điều này đã tìm thấy một lần nữa rất nhiều lực kéo trong thế giới dịch vụ web.
Đây là một tập hợp các nguyên tắc mạng phác thảo cách
tài nguyên có thể được cung cấp trên máy chủ
và các tài nguyên này có thể được truy cập từ máy khách
bằng cách xác định các tài nguyên bằng cách sử dụng các điểm cuối API còn lại.
Trong phạm vi chuyển giao Nhà nước đại diện,
có bốn nguyên tắc thiết kế cơ bản.
Đầu tiên và quan trọng nhất, REST được xây dựng dựa trên giao thức HTTP,
vì vậy nó sử dụng tất cả các phương thức HTTP mà chúng ta đã thấy trong bài học trước đó.
Thứ hai, REST được thiết kế là không có trạng thái,
nghĩa là máy chủ không lưu trữ bất kỳ thông tin nào về
trạng thái sau khi giao tiếp hoàn tất.
Vì vậy, khi một máy chủ nhận được yêu cầu, máy chủ trả lời,
và sau đó nó không nhớ
thêm bất cứ điều gì về cuộc trò chuyện giữa máy khách và máy chủ.
Thứ ba, cách REST cung cấp tài nguyên là
phơi bày một cấu trúc thư mục như URL (Uniform Resource Locators - URL).
Thứ tư, định dạng cho trao đổi dữ liệu thường là JSON
hoặc XML hoặc cả hai có thể được hỗ trợ bằng cách sử dụng REST.
Một trong những động lực cho Roy gợi ý REST như một cách để hỗ trợ các dịch vụ web
là nó nắm bắt tất cả những điều tốt đẹp về
World Wide Web và điều đó làm cho World Wide Web thành công.
Việc sử dụng Uniform Resource Indicators hoặc
Uniform Resource Locators (URL) cho phép bạn
giải quyết các tài nguyên bằng cách chỉ định chúng dưới dạng URL.
Thứ hai, là một giao thức sống trên đầu trang của giao thức HTTP.
HTTP đã tìm thấy triển khai rộng rãi trên internet.
Thứ ba, chu kỳ đáp ứng yêu cầu HTTP được biết đến với.
Vì vậy, bạn gửi một yêu cầu,
máy chủ nhận được yêu cầu của bạn, xử lý yêu cầu,
gửi phản hồi đến yêu cầu,
và khách hàng nhận được phản hồi,
hành động theo đó, và có thể tạo ra các yêu cầu khác.
Vì vậy, cách tiếp cận này của chu kỳ đáp ứng yêu cầu được
thiết lập rất tốt với HTTP và World Wide Web.
Bây giờ, giao thức HTTP như chúng ta đã thấy trước đó,
chúng ta sẽ sử dụng tất cả các động từ khác nhau mà HTTP cung cấp.
cụ thể, GET, PUT,
POST và DELETE để có thể
xác định các hoạt động được thực hiện trên tài nguyên được lưu trữ ở phía máy chủ.
Vì vậy, ví dụ, nếu bạn thực hiện một yêu cầu HTTP GET,
bạn đang yêu cầu cho máy chủ để trả về tài nguyên.
Nếu bạn thực hiện một yêu cầu POST,
bạn đang yêu cầu máy chủ để tạo một tài nguyên mới.
Nếu bạn thực hiện một yêu cầu PUT,
bạn đang yêu cầu cho máy chủ để cập nhật một tài nguyên hiện có.
Và nếu bạn phát hành một yêu cầu DELETE,
bạn đang yêu cầu máy chủ để xóa tài nguyên
được xác định bởi URL cụ thể.
Ngoài ra, nó cố gắng để bảo vệ Idempotence.
Một số hoạt động, khi chúng được thực hiện thậm chí nhiều lần,
sẽ không gây ra bất kỳ sự thay đổi nào của nhà nước.
Một số hoạt động khác, nếu bạn làm chúng liên tiếp,
chúng có thể gây ra một sự thay đổi của nhà nước.
Vì vậy, bạn cần phải cẩn thận về những hoạt động có thể được lặp lại mà không có
bất kỳ hậu quả gây hại và phải được thực hiện rất cẩn thận.
Trong thế giới REST, bạn thường nghe mọi người nói về danh từ, động từ và biểu diễn.
Bây giờ, chúng ta sẽ làm rõ từng cái trong số này một chút chi tiết hơn trong vài trang trình bày tiếp theo.
Danh từ đặc biệt đề cập đến các tài nguyên và các tài nguyên này
thường được xác định bởi các URL của chúng và chúng không bị giới hạn.
Động từ là hạn chế và những chỉ định các hành động cần
thực hiện trên các nguồn lực và biểu diễn như chúng ta thấy.
Khi thông tin cần phải được chuyển tải từ
máy chủ đến máy khách hoặc từ máy khách đến máy chủ,
làm thế nào bạn mã hóa thông tin.
Thông thường, hoặc sử dụng JSON hoặc sử dụng XML.
Tài nguyên là sự trừu tượng quan trọng mà REST hoạt động xung quanh.
Vì vậy, thông tin được trừu tượng dưới dạng một tài nguyên và tài nguyên
được xác định bằng cách chỉ định nó bằng cách sử dụng một URL.
Vì vậy, bất kỳ thông tin nào có thể được đóng gói và được cung cấp, có
thể được xác định là một nguồn tài nguyên.
Một mẩu thông tin như thời tiết hiện tại ở Hồng Kông có thể là một nguồn lực,
một hình ảnh có thể là một nguồn lực,
một thông tin giá cổ phiếu có thể là một nguồn lực và như vậy.
Vì vậy, bất cứ điều gì bạn định nghĩa như là một phần của thông tin mà một khách hàng có thể quan tâm,
có thể được xác định là một nguồn tài nguyên.
Bạn thậm chí có thể đối phó với các nguồn lực như là bộ sưu tập
các nguồn lực mà máy chủ có thể gửi lên cho khách hàng.
Một ví dụ về cách bạn đặt tên tài nguyên được minh họa ở đây.
Vì vậy, chúng tôi sử dụng URI để xác định nguồn.
Đọc nhanh các đặc tả này hoặc URI ở đây sẽ
dễ dàng cho phép bạn hiểu những gì chúng tôi đang đề cập đến bằng cách sử dụng các URI này.
Vì vậy, ví dụ, một cái gì đó kết thúc với món ăn/,
bạn tự động giả định rằng đây là đề cập đến một bộ sưu tập các món ăn.
Nhưng món ăn/123 ví dụ,
có thể có nghĩa là món ăn số 123 trong trường hợp này và như vậy.
Vì vậy, nó rất dễ dàng để lưu và bạn có thể chỉ định
một bộ sưu tập các tài nguyên và có thể xác định
chúng như là một bộ sưu tập và sau đó tải chúng dưới dạng một bộ sưu tập hoặc bạn có thể
xác định một tài nguyên cá nhân và nói rằng bạn muốn tài nguyên cụ thể đó.
Bây giờ, các tài nguyên này có thể được tổ chức thành một hệ thống phân cấp của đặc tả của URI này.
Vì vậy, khi bạn đi qua con đường,
bạn đi từ tổng quát hơn đến cụ thể hơn của tài nguyên.
Cấu trúc thư mục này cho phép bạn xác định các nguồn lực
mà bạn sử dụng hoặc cung cấp từ phía máy chủ của bạn rất dễ dàng.
Phần thứ hai của REST API là các động từ.
Đặc biệt, chúng tôi quan tâm đến bốn động từ của HTTP GET, P
UT, POST và DELETE.
Trong trường hợp này, các động từ này sẽ được ánh xạ thành các hành động mà chúng ta
muốn được thực hiện trên tài nguyên, ở phía máy chủ.
Một GET có nghĩa là bạn muốn thực hiện một thao tác đọc trên tài nguyên.
Vì vậy, có nghĩa là một khách hàng gửi một yêu cầu GET chỉ ra cho máy chủ rằng nó
muốn để có được một đại diện
của tài nguyên đó từ phía máy chủ để phía máy khách.
Một POST có nghĩa là bạn muốn tạo
một tài nguyên mới và sau đó bạn sẽ chỉ định các chi tiết của tài nguyên
trong đại diện được sử dụng
để xác định tài nguyên và sau đó gửi thông tin đó qua phía máy chủ,
do đó máy chủ sẽ tạo ra tài nguyên đó thay mặt cho bạn.
Một PUT sẽ được sửa đổi các nguồn lực và
một DELETE như bạn mong đợi là xóa các nguồn lực.
Vì vậy, như bạn có thể thấy, bốn động từ;
GET, POST, PUT và DELETE,
được ánh xạ vào bốn hoạt động CRUD mà bạn có thể thực
hiện trên một cơ sở dữ liệu lưu trữ các tài nguyên trên phía máy chủ,
các hoạt động đọc, tạo, Cập Nhật và DELETE.
Xây dựng thêm, HTTP GET là một cách xác định rằng bạn
muốn thông tin hoặc đại diện
của tài nguyên được trả lại cho khách hàng từ phía máy chủ.
Vì vậy, khi bạn đưa ra một yêu cầu GET
cho một điểm cuối API REST, bạn đang yêu cầu một tập hợp các tài nguyên đại diện bởi
URI hoặc một tài nguyên cụ thể được xác định bởi ID của tài nguyên cụ thể đó, được
chỉ định trong URL.
Vì vậy, như bạn thấy trong ví dụ này,
nếu bạn nói, món ăn/452,
bạn có nghĩa là để nói rằng món ăn số 452 với
ID 452 nên được trả lại cho phía khách hàng.
Tương tự như vậy, hoạt động POST như chúng ta thấy được sử dụng để tạo ra tài nguyên.
Vì vậy, khi bạn tạo tài
nguyên, nội dung mô tả tài nguyên sẽ ở dạng đại diện JSON hoặc đại
diện XML và sẽ được bao gồm
trong nội dung của thông báo yêu cầu được gửi đến phía máy chủ.
Vì vậy, một hoạt động POST mong đợi một đại diện
của tài nguyên trong một trong hai định dạng JSON hoặc XML trong nội dung của thông điệp yêu cầu.
Khi máy chủ nhận được thông báo yêu cầu đó,
máy chủ tạo ra tài nguyên đó ở phía máy chủ và sau đó trả về
hoặc là một cấu hình hoặc một lỗi để chỉ ra rằng việc tạo tài nguyên thất bại.
Tương tự, một thao tác PUT được sử dụng để cập nhật một tài nguyên.
Khi bạn thực hiện một thao tác PUT trên một nguồn lực ở phía máy chủ,
bạn có thể gửi lại các sửa đổi
hoặc bằng cách chỉ định một phần sửa đổi mà bạn muốn có hiệu lực trên
các tài nguyên cụ thể trong cơ thể của thư trả lời hoặc bạn có thể gửi
đại diện đầy đủ của các tài nguyên trong nội dung của tin nhắn.
Tùy thuộc vào sự sắp xếp giữa máy khách và máy
chủ, máy chủ mong đợi thông tin sẽ được truyền vào trong nội dung của thư yêu cầu.
Một thao tác DELETE như bạn mong đợi xóa tài nguyên hiện có.
Bây giờ, trong trường hợp cụ thể này,
tất nhiên một thao tác DELETE sẽ là idempotent bởi vì nếu bạn
cố gắng xóa một tài nguyên và tài nguyên tồn tại, nó sẽ bị xóa.
Nếu bạn đang cố gắng xóa một tài nguyên không tồn tại,
nó sẽ không gây ra bất kỳ sửa đổi nào cho phía máy chủ,
ngoại trừ việc máy chủ sẽ trả lời với một lỗi nói rằng tài nguyên không tồn tại.
Tuy nhiên, tuy nhiên, DELETE là một ví dụ về một hoạt động idempotent trong trường hợp này.
Tương tự như vậy, các hoạt động GET cũng là một hoạt động idempotent bởi vì nó
không thực hiện bất kỳ sửa đổi tài nguyên ở phía máy chủ.
POST và PUT tất nhiên sẽ sửa đổi tài nguyên ở phía máy chủ,
hoặc là tạo ra một tài nguyên mới hoặc sửa đổi một tài nguyên hiện có ở phía máy chủ.
Tất nhiên, các đại diện,
như tôi đã được nhấn mạnh,
hai định dạng phổ biến để đại diện là JSON hoặc XML.
Phần cuối cùng mà chúng ta cần nhấn mạnh là
phía máy chủ phải hoàn toàn không trạng thái,
có nghĩa là phía máy chủ không theo dõi
trạng thái máy khách vì nếu máy chủ cần theo dõi trạng thái máy khách thì
nó sẽ không thể mở rộng được.
Vì vậy, để thực hiện khả năng mở rộng của phía máy chủ,
bạn thường sử dụng một máy chủ không trạng thái ở phía máy chủ.
Vì vậy, mọi yêu cầu mà máy khách gửi đến máy chủ sẽ được
coi là một yêu cầu độc lập và sẽ
không phản ánh các yêu cầu trước
đó đã được xử lý bởi máy chủ từ máy khách cụ thể đó.
Vì vậy, trách nhiệm của khách hàng để theo dõi trạng thái riêng của mình,
hoặc dưới hình thức sử dụng cookie hoặc sử dụng một cơ sở dữ liệu phía khách hàng,
bất cứ phương tiện nào phù hợp.
Bây giờ, cách tiếp cận này mà khách hàng theo dõi trạng thái riêng của mình
có khả năng mở rộng hơn rất nhiều bởi vì mỗi khách hàng cá nhân
sẽ chịu trách nhiệm theo dõi trạng thái riêng của mình.
Đây là nơi thiết lập MVC phía khách hàng giúp chúng tôi trong vấn đề này.
Cuối cùng, chúng tôi chưa được thực hiện với REST.
Chúng ta sẽ thấy nhiều hơn về REST trong các bài tập theo sau trong bài học cụ thể này
và sau đó chúng ta cũng sẽ xem thêm chi tiết về việc sử dụng REST trong phần còn lại của khóa học này.