[MUSIC]
Để tôi nghỉ ngơi một chút.
Bắt được anh rồi!
Đ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.
Chính xác thì nghỉ ngơi là gì?
Làm thế nào để chúng ta sử dụng nó trong ứng dụng góc cạnh 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 Angular của chúng tôi?
Hãy nói về điều đó một chút nữa trong bài học này.
Trong bài giảng đặc biệt này, tôi sẽ cung cấp cho bạn một cái nhìn tổng quan ngắn gọn về REST.
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.
Mức bố trí ứng dụng của họ cho các
ứng dụng cơ sở dữ liệu sử dụng các tiêu 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 kết thúc giao tiếp với nhau.
Và thông thường, xà phòng được dựa trên việc sử dụng XML làm
định dạng cho các tin nhắn được trao đổi giữa hai điểm cuối.
Việc chuyển trạng thái trình bày hoặc phần còn lại 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 tă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 các dịch vụ web còn lại.
Thông thường, giao tiếp máy chủ khách được tạo điều kiện bằng cách sử dụng R
EST nơi máy chủ hỗ trợ API REST và máy khách sau đó có thể gọi
điểm cuối REST API của họ để 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 đến từ, gọi rằng điểm kết thúc 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 slide tiếp theo.
Chuyển 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ĩ đã 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 điểm cuối REST API.
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 pháp 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à để
lộ một cấu trúc thư mục như URL thống nhất định vị tài nguyên URL.
Và thứ tư định dạng của họ để 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 để tăng 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 của tất cả World Wide Web.
Và điều đó đã làm cho Word 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 đi 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 nổi tiếng 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à máy khách đó 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à Web trên toàn thế giới 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ể, cổng đặt bài xóa.
Để có thể xác định các hoạt động được thực hiện
trên các 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ề nguồn.
Nếu bạn thực hiện một yêu cầu POST, bạn đang yêu cầu cho 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 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 xóa, 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ệ sự bất lực.
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 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 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 nào.
Và điều đó 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ụ thể, chúng có đầy đủ các tài nguyên và
các tài nguyên này thường được xác định bởi URL của chúng và chúng không bị giới hạn.
Động từ bị hạn chế và những hành động được chỉ định sẽ được thực hiện trên các nguồn tài nguyên.
Và các bài thuyết trình 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ủ, cách 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 để
thông tin được trừu tượng hóa trong tài nguyên.
Và tài nguyên được xác định bằng cách xác định nó bằng cách sử dụng một URI.
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 tại Hồng Kông có thể là một nguồn tài nguyên,
một hình ảnh có thể là một nguồn tài nguyên.
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à tập hợp các nguồn lực
mà máy chủ đó có thể gửi đến 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.
Việc đọc nhanh thông số kỹ thuật hoặc các URL ở đây sẽ
dễ dàng cho phép bạn hiểu được những gì chúng tôi đang đề cập đến bằng cách sử dụng các URL 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.
Giống như 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à vân vân.
Vì vậy, rất dễ dàng để nói rằng 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 xuố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
mà đặ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 tài nguyên mà
bạn cung cấp từ trang web dịch vụ của bạn rất dễ dàng.
Phần thứ hai của REST API là các từ.
Đặc biệt, chúng tôi quan tâm đến 4 động từ của HTTP để lấy,
đặt, đăng, và xóa.
Trong trường hợp này các động từ này sẽ được ngủ trưa trong 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ủ.
GetT có nghĩa là bạn muốn thực hiện một hoạt động đọc trên tài nguyên, có nghĩa là
một khách hàng gửi một yêu cầu get là chỉ ra cho máy chủ rằng nó muốn
có được rằng trình bày của nguồn dữ liệu từ trang web máy chủ đến trang web khách hàng.
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 biểu diễn, nhưng được sử dụng để
xác định tài nguyên.
Sau đó gửi thông tin qua phía máy chủ, do
đó máy chủ sẽ tạo ra các tài nguyên thay mặt cho bạn.
Một PUT sẽ được sửa đổi các nguồn tài nguyên
, và xóa, như bạn mong đợi, là xóa các nguồn.
Vì vậy, như bạn có thể thấy bốn động từ nhận được, đăng, đặt và
xóa đượ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à xóa.
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 bản trình bày của họ về tài nguyên để được
trả lại cho khách hàng từ trang web máy chủ.
Vì vậy, khi bạn phát hành một yêu cầu GET cho một điểm cuối REST API.
Bạn đang yêu cầu một bộ sưu tập các tài nguyên được trình bày bởi
Uri hoặc một tài nguyên cụ thể được xác định bởi ID của
các tài nguyên cụ thể được xác định trong URL để như bạn thấy trong ví dụ này,
nếu bạn 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 bài, 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à điều đó 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 bài hoạt động 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.
Và máy chủ nhận được thông báo yêu cầu như vậy, máy chủ tạo ra
tài nguyên đó ở phía máy chủ và sau đó trả về hoặc là một xác nhận hoặc
một lỗi để chỉ ra rằng việc tạo tài nguyên không thành công.
Tương tự như vậy nó đặt hoạt động dễ dàng 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 tài nguyên
trong nội dung của thư, 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.
Xóa hoạt động 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 xóa sẽ là 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 thêm cho phía máy chủ Ngoại trừ
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, là một ví dụ về một hoạt động trong trường hợp này.
Tương tự như vậy, thao tác get cũng sẽ hoạt động vì nó không thực
hiện bất kỳ sửa đổi nào đối với tài nguyên trên trang web máy chủ.
Đăng nhập tất nhiên sẽ sửa đổi tài nguyên ở phía máy chủ.
Bạn cần phải tạo một tài nguyên mới hoặc
sửa đổi tài nguyên hiện có ở phía máy chủ, và tất nhiên các bài thuyết trình dữ liệu.
Như tôi đã được nhấn mạnh, hai dự phòng phổ biến cho
đại diện là một trong hai JSON XML, phần cuối cùng
mà chúng ta cần nhấn mạnh là phía máy chủ nên hoàn toàn không có trạng thái.
Có nghĩa là, phía máy chủ không theo dõi trạng thái của khách hàng.
Bởi vì, nếu máy chủ cần theo dõi trạng thái của máy khách, nó sẽ không được mở rộng.
Vì vậy, đối với một triển khai 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, nếu yêu cầu của các khách hàng được 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, đó là trách nhiệm của khách hàng để theo dõi trạng thái của chính nó.
Hoặc dưới dạng sử dụng cookie hoặc sử dụng cơ sở dữ liệu trang web của khách hàng.
Bất cứ điều gì có nghĩa là 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ì khách hàng của bạn sẽ chịu trách nhiệm theo dõi của riêng mình.
Và đâ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.
Và cuối cùng chúng ta chưa được thực hiện với REST, chúng ta sẽ thấy nhiều hơn
REST trong các bài tập tiếp theo trong bài học cụ thể này.
Và sau đó,
chúng ta 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.
[ NHẠC]