RESTful Services: Tóm tắt về HTTP

Các trang web từ lúc bắt đầu, được cấu trúc xung quanh ý tưởng các tài nguyên. Trong những ngày đầu, web chỉ là một nền tảng cho việc chia sẻ các file text/HMTL, tài liệu, hình ảnh, ...Theo cách này, web có thể được coi như một tập hợp các tài nguyên và thường được gọi là hướng tài nguyên (resource-oriented).

Khi các trang web phát triển thành một mạng lưới phức tạp của các ứng dụng liên kết với nhau, với nội dung phong phú. Các ứng dụng trở lên phức tạp, với nhiều chức năng.

Các service cung cấp một phương tiện để khai thác các chức năng của các ứng dụng web cho client. Nói chung, các ứng dụng lớn có thể cung cấp các chương trình truy cập tới nền tảng của mình cho các lập trình viên khác và có thể làm điều đó bằng cách sử dụng các service.

Ngoài ra, các service có thể được sử dụng để chia một ứng dụng thành nhiều đơn vị logic khác nhau, tương tác với nhau để tạo ra kết quả cuối cùng. Trong trường hợp này, một service hoạt động như một khách hàng của các service khác.

Các service là một thành phần quan trọng của các ứng dụng web, các lập trình viên luôn cố gắng và đảm bảo rằng chúng được thiết kế theo cách có thể mở rộng, hiệu quả và tiết kiệm chi phí nhất có thể - cả về kỹ thuật và kinh tế.

Hãy đi vào REST! REST là viết tắt của REpresentational State Transfer, là một phong cách kiến trúc nhằm tận dụng tất cả các cấu trúc web, cái đã cho phép Web phát triển trong một vài thập kỷ gần đây. Nó sử dụng điều đó như các nguyên tắc hướng dẫn cho việc thiết kết các web service.

Khi tất cả kết nối trên Web diễn ra thông qua HTTP, REST bị ràng buộc chặt chẽ với nó và sử dụng nhiều ý tưởng tương tự. Vì vậy, để hiểu về REST cần hiểu các khái niệm cơ bản của HTTP. Đây là chủ đề trong phần còn lại của bài viết này.

Hầu hết các ứng dụng web được xây dựng xung quanh một mô hình client-server. Một client có thể là một cái gì đó đơn giản như trình duyệt web, một ứng dụng mobile hoặc thậm chí các web service khác.

Tương tự, các server có thể được thực hiện theo nhiều cách, sử dụng các stack công nghệ, ngôn ngữ khác nhau và phục vụ các kiểu dữ liệu khác nhau.

Để thích ứng với sự đa dạng này, các client và server phải đồng ý một tập hợp các qui ước - cái gọi là giao thức (protocol) - nó áp dụng cho tất cả các kết nối giữa chúng. Giao thức này cho phép một web server nhận thông tin - các request - được gửi bởi client, xử lý chúng, và đáp trả thích hợp.

Các ứng dụng web ngày nay sử dụng Hypertext Transfer Protocol, thường được viết tắt là HTTP, để trao đổi thông tin.

Về bản chất, điều này cung cấp một định dạng cấu trúc cho việc trao đổi thông tin qua web. Như chúng ta sẽ thấy, HTTP đưa ra một tập hợp các hướng dẫn để mô tả kiểu dữ liệu được trao đổi - cùng với định dạng, tính hợp lệ, và các thuộc tính khác.

Trong quá khứ, các ứng dụng thường dựa trên HTTP như một cơ chế truyền phát. Các client và server trao đổi dữ liệu sử dụng HTTP. Các quy ước khác sau đó phải được phát triển cho dữ liệu. Một ví dụ về mô hình như vậy là SOAP, một trong những đối thủ của REST.

Và điều tuyệt vời về HTTP là nó đã có các cấu trúc cần thiết cho các hành động cụ thể với tài nguyên (client request), cũng như kết quả của các hành động (server response). Hãy xem xét chúng!

URL là một trong những khái niệm quan trọng và hữu ích nhất của Web. Nó cũng là khái niệm quen thuộc với hầu hết người sử dụng. URL là viết tắt của Uniform Resource Locator và được sử dụng để xác định địa chỉ tài nguyên trên Web.

Một URL thường bao gồm các thành phần sau:

• Giao thức (Protocol): đây là giao thức yêu cầu phục vụ. Thường là HTTP (hoặc phiên bản bảo mật HTTPS). Các giao thức khác chẳng hạn SMTP và FTP có thể được sử dụng thay thế, nhưng chúng ta sẽ chỉ giới hạn với HTTP.

• Tên miền (Domain): đây là tên miền của máy chủ chứa tài nguyên. Tên miền có thể được thay thế bằng địa chỉ IP, cái thường được sử dụng bởi một DNS.

• Đường dẫn (Path): đây là vị trí của tài nguyên trên server. Nó có thể là vị trí của tài nguyên trong hệ thống (VD /search/files/myFile.txt) mặc dù điều này hiếm khi được sử dụng trong thực tế. Cách phổ biến là các đường dẫn dựa trên quan hệ giữa các tài nguyên (VD myBlog/blog/comments) nơi blog và các comment là 2 tài nguyên khác nhau. Điều này sẽ được nói rõ hơn trong phần 2 của loạt bài này.

• Các tham số (Parameters): đây là dữ liệu bổ sung, truyền trong định dạng key-value, cái có thể được sử dụng bởi server để xác định tài nguyên, hoặc lọc một danh sách các tài nguyên.

• Fragment: fragment đề cập tới một khu vực trong tài nguyên và thường được áp dụng cho các tài liệu. Điều này có thể giống như đánh dấu trong tài liệu được trả lại và hướng dẫn trình duyệt di chuyển tới nội dung tại điểm được đánh dấu. Ví dụ, các tài liệu HTML trình duyệt sẽ cuộn tới phần tử được xác định bởi anchor (thẻ <a>). Các fragment cũng được đề cập như các anchor (thẻ <a>).

HTTP định nghĩa một tập hợp các phương thức, cũng được gọi là "các động từ", cái client sử dụng để miêu tả kiểu request được tạo. Mỗi request có thể coi như một hành động cụ thể trên một tài nguyên. Ví dụ, một client có thể request để thêm, xóa, cập nhật hoặc đơn giản đọc một tài nguyên.

Trong HTTP điều này tương đương với việc tạo các request POST, DELETE, PUT hoặc GET. POST và PUT chứa các dữ liệu để thêm mới hoặc cập nhật. Chúng ta sẽ khám phá các phương thức này khi nói về REST trong phần tới.

Ngoài ra còn có 2 phương thức ít sử dụng hơn là OPTIONS và HEAD.

• OPTIONS request là cung cấp cho client thông tin về các phương thức có thể được sử dụng để tương tác với tài nguyên.

• HEAD request là một trường hợp khác, nó hữu ích hơn một chút. Một HEAD request bắt chiếc GET request, ngoại trừ nó bỏ qua body của response. Về bản chất, client nhận một response giống hệt cái sẽ nhận từ một GET request, với cùng meta data, nhưng không có response body. Điều này hữu ích bởi vì nó cung cấp một cách nhanh chóng để kiểm tra các response header và sự tồn tại của tài nguyên.

Một điểm quan trọng của HTTP là nó phân biệt một phương thức an toàn hay không an toàn. Một phương thức được gọi là an toàn nếu nó không chỉnh sửa tài nguyên. Nói cách khác, request là các thao tác "chỉ đọc (read-only)". Ví dụ, tạo một GET (hoặc HEAD) request cho một tài nguyên trên một server sẽ không thay đổi nó. Tất cả các phương thức khác mặc định là không an toàn.

Cuối cùng là khái niệm idempotent. Một phương thức HTTP được gọi là idempotent nếu lặp lại một request dẫn tới cùng một kết quả. Giống như khi các tham số của request không thay đổi, request có thể được tạo nhiều lần và tài nguyên có trạng thái như khi request chỉ tạo một lần duy nhất.

GET, OPTIONS và HEAD là các phương thức idempotent tự nhiên, cũng như chúng là các thao tác chỉ đọc. Ngoài ra các phương thức PUT và DELETE cũng được mô tả như idempotent. Điều này bởi vì cập nhật mọi tài nguyên với cùng một tham số hết lần này đến lần khác dẫn tới cùng một kết quả cuối cùng.

Có thể hơi khó hiểu khi DELETE cũng là idempotent. Xem xét cái xảy ra với hệ thống khi có nhiều DELETE request đồng thời. DELETE request đầu tiên sẽ xóa tài nguyên. Tạo ra nhiều DELETE request lúc này sẽ không làm thay đổi trạng thái của hệ thống. Hệ thống sẽ tiếp tục giữ nguyên trạng thái sau khi DELETE request đầu tiên được thực hiện.

Các mã trạng thái của HTTP cung cấp thông tin về kết quả của một request và cách để giải thích nó. Ví dụ, nếu chúng ta tạo một request để nhận một file từ một web server, tôi sẽ mong muốn thấy một response với mã trạng thái mô tả request của tôi đã thành công. Nếu không, mã trạng thái sẽ cung cấp cho tôi lý do tại sao request thất bại.

HTTP định nghĩa nhiều mã trạng thái, mỗi cái có một ý nghĩa cụ thể. Một vài loại phổ biến là:

• 2xx: Các mã trạng thái rơi vào series 2xx có nghĩa là request thành công và không có lỗi. Mã 200 là ví dụ thường thấy.

• 3xx: Một mã trong series 3xx có nghĩa là chuyển hướng. Điều này có nghĩa là máy chủ chuyển hướng đến một nơi khác để nhận request.

• 4xx: Một lỗi 4xx ví dụ 400, 403, 404, ... được sử dụng khi có một lỗi trong request. Điều này có thể do nhiều nguyên nhân, chẳng hạn truy cập trái phép tới một tài nguyên, hoặc tài nguyên không tồn tại, các tham số không hợp lệ, ...

• 5xx: Cuối cùng một response 5xx được sử dụng khi có lỗi ở phí server. Điều này có nghĩa là server biết lỗi và không thể xử lý request. Thông thường, response kèm theo một mô tả ngắn gọn về nguyên nhân có thể gây ra lỗi.

Headers là một phần thiết yếu của một kết nối HTTP. Chúng cung cấp thông tin cho việc xử lý các request và response. Chú ý header không liên quan tới việc xác định tài nguyên. Chúng thường là các cặp key-value và cung cấp các thông tin chẳng hạn chính sách cache (cache policy) cho response, các loại response được client chấp nhận, ngôn ngữ ưa thích của response, mã hóa, ...

Thông tin cho việc xác thực và cho phép - chẳng hạn các token truy cập - cũng thường được truyền sử dụng Authorization header.

Tương tự, server cũng có thể sử dụng response headers để thiết lập các cookie trên client và lấy chúng với cùng cơ chế.

Chú ý với HTTPS: để tránh nhầm lẫn cũng cần hiểu sự khác biệt giữa HTTPS và HTTP thường. Cả HTTP và HTTPS sử dụng cùng một cơ chế để truyền thông tin, nhưng HTTPS bảo mật hơn. Dữ liệu truyền qua HTTPS được mã hóa hoàn toàn. Đây là một yếu tố quan trọng khi thông tin cần giữ bí mật, chẳng hạn như dữ liệu tài chính hoặc thông tin cá nhân của người dùng.

Bài viết được dịch từ: medium.freecodecamp.com