Phần 1: REST là gì Trong phần này chúng ta sẽ xem xét kỹ hơn cách giao tiếp diễn ra giữa máy khách và máy chủ. Trong quá trình thực hiện, chúng tôi sẽ tiết lộ các điều khoản mới và đưa ra lời giải thích cho chúng. Để làm cho mọi thứ trở nên rõ ràng, chúng tôi sẽ phân tích giao tiếp giữa máy khách và máy chủ bằng cách sử dụng ví dụ về một số ứng dụng RESTful. Giả sử chúng ta đang phát triển một ứng dụng web có khả năng lưu trữ thông tin về khách hàng và đơn đặt hàng của họ. Những thứ kia. hệ thống của chúng tôi có khả năng thao túng một số thực thể: tạo, chỉnh sửa, xóa chúng và cung cấp thông tin về chúng. Những thực thể này sẽ là:
khách hàng - khách hàng;
đơn đặt hàng - đơn đặt hàng của khách hàng;
mặt hàng - hàng hóa.
Trong kiến trúc REST, máy khách gửi yêu cầu đến máy chủ để lấy hoặc sửa đổi dữ liệu và máy chủ gửi phản hồi cho máy khách theo yêu cầu của họ.
Yêu cầu
Các yêu cầu của khách hàng hầu như luôn được thực hiện qua HTTP. Nói chung, các yêu cầu HTTP bao gồm một số thành phần:
phương thức HTTP;
tiêu đề;
URI;
thân yêu cầu.
Dưới đây chúng ta sẽ xem xét từng phần thành phần chi tiết hơn.
URI và tài nguyên
Dữ liệu mà khách hàng có được hoặc sửa đổi thông qua các yêu cầu được gọi là tài nguyên. Cơ sở của sự tương tác giữa máy khách và máy chủ là việc thao túng tài nguyên. Tài nguyên trong REST là bất cứ thứ gì có thể được đặt tên. Theo một nghĩa nào đó, đây giống như các lớp trong Java. Trong Java chúng ta có thể tạo một lớp cho bất cứ thứ gì. Điều này cũng tương tự trong REST - tài nguyên có thể là bất kỳ thứ gì: người dùng, tài liệu, báo cáo, đơn đặt hàng. Tất cả điều này có thể là sự trừu tượng của một số thực thể hoặc một cái gì đó cụ thể, chẳng hạn như một tệp - hình ảnh, video, hoạt ảnh, tệp PDF. Ví dụ của chúng tôi, chúng tôi có 3 tài nguyên:
khách hàng - khách hàng;
đơn đặt hàng - đơn đặt hàng của khách hàng;
mặt hàng - hàng hóa.
Khách hàng gửi yêu cầu đến cái gọi là điểm cuối hoặc điểm cuối. Nói một cách đơn giản, điểm cuối giống như một địa chỉ trên mạng. Để đi sâu hơn, điểm cuối là URI : một chuỗi ký tự xác định tài nguyên vật lý hoặc trừu tượng. Mã định danh tài nguyên thống nhất - mã định danh tài nguyên thống nhất. Đôi khi điểm cuối hoặc URI được gọi là đường dẫn - đường dẫn đến tài nguyên. Với mục đích của bài viết này, chúng tôi sẽ sử dụng thuật ngữ URI. Mỗi tài nguyên cụ thể phải có một URI duy nhất. Trách nhiệm đảm bảo rằng mỗi tài nguyên luôn có URI riêng thuộc về nhà phát triển máy chủ. Trong ví dụ của chúng tôi, chúng tôi là nhà phát triển, vì vậy chúng tôi sẽ làm theo cách mà chúng tôi biết. Giống như trong cơ sở dữ liệu quan hệ, người ta thường đặt khóa chính thành một ID số nhất định, trong REST mỗi tài nguyên có ID riêng. Điều thường xảy ra là ID của tài nguyên trong REST khớp với ID của bản ghi trong cơ sở dữ liệu nơi lưu trữ thông tin về tài nguyên này. REST URI thường bắt đầu bằng dạng số nhiều của danh từ mô tả một số tài nguyên. Ví dụ, từ từ khách hàng. Tiếp theo, ID được biểu thị bằng dấu gạch chéo - mã nhận dạng của một khách hàng cụ thể. Ví dụ:
/clients - URI của tất cả các client hiện có;
/clients/23 - URI của một ứng dụng khách cụ thể, cụ thể là ứng dụng khách có ID=23;
/clients/4 - URI của một ứng dụng khách cụ thể, cụ thể là ứng dụng khách có ID=4.
Nhưng đó không phải là tất cả. Chúng ta có thể mở rộng URI bằng cách thêm các đơn hàng vào nó:
/clients/4/orders — URI của tất cả các đơn hàng của khách hàng số 4;
/clients/1/orders/12 - URI của đơn hàng số 12 của khách hàng số 1.
Nếu chúng ta tiếp tục chuỗi này và thêm hàng hóa, chúng ta sẽ nhận được:
/clients/1/orders/12/items — URI của danh sách tất cả các sản phẩm theo thứ tự số 12 do khách hàng số 1 tạo.
Với các cấp độ lồng nhau, điều quan trọng là làm cho URI trở nên trực quan.
Phương thức HTTP
Phương thức HTTP (Phương thức HTTP tiếng Anh) là một chuỗi gồm bất kỳ ký tự nào, ngoại trừ các điều khiển và dấu phân cách, cho biết thao tác chính trên một tài nguyên. Có một số phương thức HTTP phổ biến. Chúng tôi liệt kê những thứ thường được sử dụng nhất trong các dịch vụ RESTful:
NHẬN - được sử dụng để lấy thông tin về một tài nguyên cụ thể (thông qua ID) hoặc bộ sưu tập tài nguyên;
POST - được sử dụng để tạo tài nguyên mới;
PUT - được sử dụng để thay đổi tài nguyên (thông qua ID);
DELETE - được sử dụng để xóa tài nguyên (thông qua ID).
Tiêu đề
Các yêu cầu cũng như phản hồi đều chứa các tiêu đề HTTP. Họ gửi thông tin bổ sung về yêu cầu (hoặc phản hồi). Tiêu đề là cặp khóa-giá trị. Bạn có thể đọc danh sách các tiêu đề phổ biến nhất trên trang Wikipedia . Với REST, khách hàng thường có thể gửi tiêu đề Chấp nhận trong yêu cầu của họ tới máy chủ. Cần phải cho máy chủ biết máy khách mong đợi nhận được phản hồi từ nó ở định dạng nào. Các tùy chọn định dạng khác nhau được trình bày trong danh sách được gọi là loại MIME. MIME (Phần mở rộng thư Internet đa năng) là thông số kỹ thuật để mã hóa thông tin và định dạng thư để chúng có thể được gửi qua Internet. Mỗi loại MIME bao gồm hai phần, được phân tách bằng dấu gạch chéo: một loại và một loại phụ. Ví dụ về các loại MIME cho các loại tệp khác nhau:
văn bản - văn bản/thuần túy, văn bản/css, văn bản/html;
hình ảnh - hình ảnh/png, hình ảnh/jpeg, hình ảnh/gif;
Tiêu đề này cho máy chủ biết rằng máy khách mong muốn nhận được phản hồi ở định dạng JSON.
Nội dung yêu cầu
Một tin nhắn được gửi bởi khách hàng đến máy chủ. Yêu cầu có nội dung hay không phụ thuộc vào loại yêu cầu HTTP. Ví dụ: các yêu cầu NHẬN và XÓA thường không chứa bất kỳ nội dung yêu cầu nào. Nhưng PUT và POST có thể chứa: tất cả là về mục đích chức năng của loại yêu cầu. Rốt cuộc, để nhận dữ liệu và xóa nó theo id (được truyền trong URL), bạn không cần phải gửi thêm dữ liệu đến máy chủ. Nhưng để tạo tài nguyên mới (yêu cầu POST), bạn cần chuyển tài nguyên này. Điều tương tự cũng xảy ra với việc sửa đổi tài nguyên hiện có. Trong REST, các định dạng XML hoặc JSON thường được sử dụng nhiều nhất để truyền nội dung yêu cầu. Định dạng phổ biến nhất là JSON. Giả sử chúng ta muốn gửi yêu cầu đến máy chủ và tạo một tài nguyên mới trong đó. Nếu bạn còn nhớ, để làm ví dụ, chúng ta đã xem xét một ứng dụng quản lý đơn đặt hàng của khách hàng. Giả sử chúng ta muốn tạo một khách hàng mới. Trong trường hợp của chúng tôi, chúng tôi lưu trữ thông tin sau về khách hàng: Tên Email Số điện thoại Sau đó, nội dung của yêu cầu như vậy có thể là JSON sau:
Chỉnh sửa khách hàng số 1 như sau:
Tên - Ben
Email - bigben@jr.com
Tel. — +380 (190) 346-42-13
DELETE /clients/12/orders/6
Xóa đơn hàng số 6 của khách hàng số 12 khỏi hệ thống
Câu trả lời
Hãy nói vài lời về phản hồi của máy chủ. Câu trả lời thường bao gồm các phần sau:
mã phản hồi;
tiêu đề;
cơ quan phản ứng.
Nhìn chung, tiêu đề phản hồi không khác nhiều so với tiêu đề yêu cầu. Ngoài ra, một số tiêu đề được sử dụng trong cả phản hồi và yêu cầu. Tôi nghĩ mọi thứ đều rõ ràng với nội dung của câu trả lời. Cơ thể thường trả về thông tin mà khách hàng yêu cầu. Thông tin có thể được trả về ở cùng định dạng JSON cho các yêu cầu GET. Nhưng phần cuối thú vị hơn một chút.
Mã phản hồi HTTP
Chúng ta hãy xem xét kỹ hơn các mã phản hồi HTTP. Đây là trích dẫn từ Wikipedia: Mã trạng thái HTTP là một phần của dòng đầu tiên trong phản hồi của máy chủ đối với các yêu cầu thông qua giao thức HTTP. Đó là một số nguyên có ba chữ số thập phân. Chữ số đầu tiên cho biết loại điều kiện. Mã phản hồi thường được theo sau bởi một cụm từ giải thích bằng tiếng Anh, cách nhau bằng dấu cách, giải thích cho người đó lý do cho phản hồi cụ thể này. Ví dụ:
201 Đã tạo;
401 trái phép;
507 Lưu trữ không đủ.
Máy khách tìm hiểu từ mã phản hồi về kết quả yêu cầu của mình và xác định hành động cần thực hiện tiếp theo. Mã phản hồi được chia thành nhiều nhóm:
1ХХ - thông tin;
2ХХ - thông báo về các trường hợp chấp nhận và xử lý thành công yêu cầu của khách hàng;
3XX - thông báo cho khách hàng rằng để hoàn thành thao tác thành công, cần phải thực hiện một yêu cầu khác, thường sử dụng một URI khác;
4ХХ - lỗi máy khách. Ví dụ: một yêu cầu được xây dựng không chính xác hoặc mã 404 Not Found nổi tiếng, có thể xảy ra khi khách hàng yêu cầu một tài nguyên không tồn tại;
5ХХ - lỗi máy chủ. Trả về cho client nếu thao tác không thành công do lỗi của server.
GO TO FULL VERSION