CodeGym /Blog Java /Ngẫu nhiên /Tổng quan về REST. Phần 2: Giao tiếp giữa client và serve...
John Squirrels
Mức độ
San Francisco

Tổng quan về REST. Phần 2: Giao tiếp giữa client và server

Xuất bản trong nhóm
Tổng quan về REST. Phần 1: REST là gì? Trong phần này, chúng ta sẽ đi sâu tìm hiểu cách giao tiếp diễn ra giữa máy khách và máy chủ. Trên đường đi, chúng tôi sẽ khám phá các thuật ngữ mới và giải thích chúng. Tổng quan về REST.  Phần 2: Giao tiếp giữa client và server - 1Để đảm bảo mọi thứ đều rõ ràng, chúng tôi sẽ phân tích giao tiếp máy khách-máy chủ bằng ứng dụng RESTful làm ví dụ. Giả sử chúng ta đang phát triển một ứng dụng web lưu trữ thông tin về khách hàng và đơn đặt hàng của họ. Nói cách khác, hệ thống của chúng tôi có thể thực hiện các thao tác trên một số thực thể nhất định: tạo, chỉnh sửa và xóa chúng cũng như hiển thị 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 (sản phẩm)
Trong kiến ​​trúc RESTful, máy khách gửi yêu cầu đến máy chủ để truy xuất hoặc sửa đổi dữ liệu, sau đó máy chủ gửi phản hồi cho máy khách đối với yêu cầu của họ.

yêu cầu

Các yêu cầu của máy khách hầu như luôn được thực hiện bằng giao thức 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
  • cơ thể yêu cầu
Dưới đây chúng tôi sẽ xem xét từng thành phần chi tiết hơn.

URI và tài nguyên

Dữ liệu mà khách hàng nhận được hoặc sửa đổi thông qua các yêu cầu được gọi là tài nguyên. Giao tiếp máy khách-máy chủ là tất cả về thao tác tài nguyên. Trong REST, tài nguyên là bất cứ thứ gì bạn có thể đặt tên. Theo một nghĩa nào đó, chúng 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 kỳ thứ gì. Vì vậy, 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. Nó 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ư hình ảnh, video, hoạt ảnh hoặc tệp PDF. Trong 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 (sản phẩm)
Khách hàng gửi yêu cầu đến các vị trí tài nguyên được gọi là đ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. Tìm hiểu sâu hơn, chúng ta có thể nói rằng điểm cuối là một URI, tức là một chuỗi các ký tự xác định một tài nguyên trừu tượng hoặc vật lý. Mã định danh tài nguyên thống nhất (URI) Đôi khi, điểm cuối hoặc URI được gọi là đường dẫn, nghĩa là đường dẫn đến tài nguyên. Đối 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. Nhà phát triển máy chủ chịu trách nhiệm đảm bảo rằng mỗi tài nguyên luôn có URI riêng. 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 chúng tôi biết. Giống như thông lệ thường gán các mã định danh số làm khóa chính trong cơ sở dữ liệu quan hệ, mỗi tài nguyên cũng có ID riêng trong REST. ID tài nguyên trong REST thường khớp với ID của bản ghi trong cơ sở dữ liệu lưu trữ thông tin về tài nguyên. Các URI REST thường bắt đầu bằng dạng số nhiều của một danh từ mô tả một số tài nguyên. Ví dụ, "
  • /customers — URI của tất cả các khách hàng có sẵn
  • /customers/23 — URI của một khách hàng cụ thể, tức là khách hàng có ID=23
  • /customers/4 — URI của một khách hàng cụ thể, tức là khách hàng có ID=4.
Nhưng đó không phải là tất cả. Chúng tôi có thể mở rộng URI bằng cách thêm các đơn đặt hàng:
  • /customers/4/orders — URI của tất cả các đơn đặt hàng của khách hàng số 4
  • /customers/1/orders/12 — URI của đơn đặt hàng số 12 do khách hàng số 1 thực hiện.
Nếu chúng tôi tiếp tục mở rộng bằng cách thêm nhiều sản phẩm, chúng tôi sẽ nhận được:
  • /customers/1/orders/12/items — URI của danh sách tất cả các sản phẩm trong đơn hàng số 12 được thực hiện bởi khách hàng số 1.
Khi chúng tôi thêm các mức độ lồng nhau, điều quan trọng là làm cho các URI trở nên trực quan.

phương thức HTTP

Phương thức HTTP là một chuỗi gồm bất kỳ ký tự nào (ngoại trừ ký tự điều khiển và dấu phân cách), cho biết thao tác chính đang được thực hiện trên tài nguyên. Có một số phương thức HTTP phổ biến. Chúng tôi sẽ liệt kê những thứ được sử dụng thường xuyên nhất trong các dịch vụ RESTful:
  • NHẬN — Nhận thông tin về một tài nguyên cụ thể (thông qua ID của nó) hoặc về một tập hợp các tài nguyên
  • POST — Tạo tài nguyên mới
  • PUT — Thay đổi tài nguyên (thông qua ID của nó)
  • DELETE — Xóa một tài nguyên (thông qua ID của nó)

tiêu đề

Các yêu cầu cũng như các phản hồi đều chứa các tiêu đề HTTP. Họ truyền đạt thông tin bổ sung về yêu cầu (hoặc phản hồi). Tiêu đề là các cặp khóa-giá trị. Bạn có thể xem danh sách các tiêu đề phổ biến nhất trên Wikipedia . Đối với REST, các máy khách thường gửi tiêu đề "Chấp nhận" trong các yêu cầu tới máy chủ. Tiêu đề này là cần thiết để cho máy chủ biết định dạng mà máy khách mong muốn nhận được phản hồi. Các định dạng khác nhau được đưa ra trong danh sách các loại MIME. MIME (Phần mở rộng thư Internet đa năng) là một đặc điểm 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à 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/đơn giản, 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
  • âm thanh — âm thanh/wav, âm thanh/mpeg
  • video — video/mp4, video/ogg
  • ứng dụng — ứng dụng/json, ứng dụng/pdf, ứng dụng/xml, ứng dụng/octet-stream
Ví dụ: một yêu cầu có thể có tiêu đề như sau:

Accept:application/json
Tiêu đề này cho máy chủ biết rằng máy khách mong nhận được phản hồi ở định dạng JSON.

cơ thể yêu cầu

Đây là thông báo do máy khách gửi đến máy chủ. Yêu cầu có phần thân 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ỳ phần thân yêu cầu nào. Nhưng các yêu cầu PUT và POST thì có thể — nó chỉ phụ thuộc vào mục đích của yêu cầu. Xét cho cùng, để nhận và/hoặc xóa dữ liệu bằng ID (được chuyển vào URL), bạn không cần gửi thêm dữ liệu đến máy chủ. Nhưng để tạo tài nguyên mới (thông qua yêu cầu POST), bạn cần gửi tài nguyên. Điều này cũng đúng đối với việc sửa đổi một tài nguyên hiện có. Trong REST, phần thân yêu cầu thường được gửi ở định dạng XML hoặc JSON. Định dạng JSON là phổ biến nhất. Giả sử chúng tôi muốn gửi yêu cầu đến máy chủ để tạo tài nguyên mới. Nếu bạn chưa quên, chúng tôi đã xem xét ví dụ về ứ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ữ các thông tin khách hàng sau: Tên, email, số điện thoại. Sau đó, phần thân của yêu cầu có thể là JSON sau:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

Tập hợp các yêu cầu lại với nhau

Vì vậy, chúng tôi đã kiểm tra những gì có thể có trong yêu cầu của khách hàng. Bây giờ chúng tôi sẽ đưa ra một số ví dụ về yêu cầu cùng với mô tả
Lời yêu cầu Sự miêu tả

GET /customers/23
Accept : application/json, application/xml
Nhận thông tin về khách hàng số 23 ở định dạng JSON hoặc XML

POST /customers
{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}
Tạo một khách hàng mới với các trường sau:
Tên — Amigo
Email — amigo@jr.com
Số điện thoại — +1 (222) 333-4444

PUT /customers/1
{
  "name" : "Ben",
  "email" : "bigben@jr.com",
  "phone" : "+86 (868) 686-8686"
}
Chỉnh sửa khách hàng số 1 như sau:
Tên — Ben
Email — bigben@jr.com
Số điện thoại — +86 (868) 686-8686

DELETE /customers/12/orders/6
Xóa đơn hàng số 6 của khách hàng số 12 khỏi hệ thống

phản hồi

Hãy nói vài lời về phản hồi của máy chủ. Một phản hồi thường bao gồm các phần sau:
  • mã phản hồi
  • tiêu đề
  • cơ thể phản ứng
Nói 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ứ cũng rõ ràng về nội dung yêu cầu. Cơ thể thường trả về thông tin theo yêu cầu của khách hàng. Thông tin được trả về để đáp ứng các yêu cầu GET cũng có thể ở định dạng JSON. Nhưng phần cuối thú vị hơn một chút.

Mã phản hồi HTTP

Hãy xem xét mã phản hồi HTTP chi tiết hơn. 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 được thực hiện qua giao thức HTTP. Nó là một số nguyên bao gồm ba chữ số thập phân. Chữ số đầu tiên cho biết loại mã trạng thái phản hồi. 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 phân tách bằng dấu cách. Cụm từ này là một lý do mà con người có thể đọc được cho câu trả lời. Ví dụ:
  • 201 đã tạo
  • 401 trái phép
  • 507 Dung lượng lưu trữ không đủ
Mã phản hồi cho khách hàng biết kết quả của yêu cầu và cho phép khách hàng xác định hành động nào sẽ thực hiện tiếp theo. Mã phản hồi được chia thành nhiều loại hoặc nhóm:
  • 1XX — Thông tin
  • 2XX — Các mã này cho biết yêu cầu của khách hàng đã được nhận và xử lý thành công
  • 3XX — Các mã này thông báo cho khách hàng rằng một yêu cầu bổ sung, thường là đối với một URI khác, phải được thực hiện để hoàn tất thành công thao tác
  • 4XX — Lỗi máy khách. Các mã như vậy có thể là kết quả của một yêu cầu được viết không chính xác. Một ví dụ khác là mã "404 Not Found" nổi tiếng, có thể xảy ra khi khách hàng yêu cầu tài nguyên không tồn tại
  • 5XX — Lỗi máy chủ. Các mã này được trả lại cho máy khách nếu máy chủ chịu trách nhiệm về lỗi hoạt động
Tổng quan về REST. Phần 3: Xây dựng dịch vụ RESTful trên Spring Boot
Bình luận
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION