Tìm hiểu về REST(tiếp)

Bài trước là định nghĩa, và bài này là 1 số ví dụ cụ thể cho các bạn hiểu rõ hơn về REST

Nhận diện tài nguyên : hệ thống cần cung cấp giải pháp để nhận diện được các tài nguyên trong hệ thống, thông thường nó dùng đường dẫn tuyệt đối tới tài nguyên đó. Mỗi route cho ta dữ liệu xác định về các đối tượng cụ thể:

GET /api/v1/books/last

Đây là giải pháp không theo REST vì cái route này trỏ đến nhiều thằng khác nhau theo thời gian. Với REST với mỗi route là tài nguyên xác định mà thôi

GET /api/v1/books/harry-potter-and-the-deathly-hollows

Vậy làm sao ta có được dữ liệu cuốn sách gần nhất, hãy sử dụng các query string

GET /api/v1/books?limit=1&sort=created_at

Có nhiều tranh luận về việc không sử dụng id trong REST, nghĩa là bạn không nên lấy một giá trị số (id của dữ liệu trong cơ sở dữ liệu chẳng hạn ) đại diện cho một resource vì nó mất đi tính đại diện cho resource đó . Ví dụ

GET /api/v1/books/j-k-rowling/harry-potter-and-the-deathly-hollows

Route của bạn khá rõ ràng còn nếu bạn dùng ID thì

GET /api/v1/books/55/3

Tùy biến hiển thị dữ liệu : Như các bạn biết một resource có nhiều cách thức hiển thị vậy làm sao để người dùng có thể lựa chọn được nó. Có 2 giải pháp:

• Content Negotiation - Nhét các yêu cầu vào trong header nếu dùng HTTP ví dụ "Accept: text/html;"
• Sử dụng mở rộng file

GET /api/v1/books .json
GET /api/v1/books .xml

Rõ ràng cách 2 trông có vẻ là dễ sư dụng hơn nhưng nó khó tùy biến hơn so với cách 1.

Chuẩn hóa tương tác với tài nguyên. Chúng ta đã xác định được vị trí tài nguyên, chúng ta cần tương tác với nó CRUD. Từ khi REST dử dụng HTTP như chuẩn khởi tạo hệ thống, nó giới hạn một số các method để tương tác với tài nguyên. Chúng ta sử dụng GET để truy xuất đọc dữ liệu, POST để đưa dữ liệu mới lên server. PUT để cập nhật dữ liệu và DELETE để xóa dữ liệu. Đôi khi POST và PUT hoán đổi cho nhau. Bạn có thể đánh giá cấp độ sử dụng REST trong hệ thống theo hình sau :

Rõ ràng hơn với REST:

PUT /api/v1/blogposts/12342 ?action=like
GET /api/v1/books ?q=[SEARCH-TERM]
GET /api/v1/authors ?filters=[COMMA SEPARATED LIST OF FILTERS]

• Dữ liệu mô tả : Để có thể thực hiện ràng buộc về chuẩn hóa giao tiếp. Dữ liệu trả về của hệ thống REST cần chưa các thông tin về thằng trả dữ liệu về nữa. Nó tuân thủ theo một cài cái chuẩn như HATEOAS (s Hypermedia as the Engine of Application State). Hiểu đơn giản là hệ thống của bạn gồm nhiều services làm sao để thằng client biết nó đang tương tác với thằng nào để lần sau nó tương tác trực tiếp với thằng đó thôi, bên cạnh đó nó cũng cần mô tả rõ loại dữ liệu , cấu trúc lấy dữ liệu nữa . Ví dụ :

{
 "metadata": {
   "links": [
     "books": {
       "uri": "/books",
       "content-type": "application/json"
     },
     "authors": {
       "uri": "/authors",
       "content-type": "application/json"
     }
   ]
 }
}

phần này giúp cho dữ liệu bạn nhận được dễ hiểu hơn và giúp client thuận tiện có thông tin để tiếp tục tương tác. Dữ liệu metadata có thể bao gồm đầy đủ các mô tả về action nâng cao, hoặc các thuộc tính hỗ trợ trong hệ thống. từ đó giúp client có thể dễ dàng tùy biến dữ liệu . Ví dụphần này giúp cho dữ liệu bạn nhận được dễ hiểu hơn và giúp thằng client thuận tiện có thông tin để tiếp tục tương tác. Dữ liệu metadata có thể bao gồm đầy đủ các mô tả về action nâng cao, hoặc các thuộc tính hỗ trợ trong hệ thống. từ đó giúp client có thể dễ dàng tùy biến dữ liệu . Ví dụ:

 "links": {
   "next": {
     "uri": "/books?page=1",
     "content-type": "application/json"
   }
 }