Phương thức HTTP QUERY mới
(kreya.app)Giải thích về phương thức HTTP QUERY mới được định nghĩa trong RFC 10008
Trong các RESTful API hiện có, cả GET và POST đều có những giới hạn khi xử lý tìm kiếm phức tạp. Để giải quyết vấn đề này, sau một thời gian dài thảo luận, phương thức QUERY đã được chuẩn hóa.
Giới hạn của GET
- Khi gửi các bộ lọc phức tạp hoặc truy vấn quan hệ bằng tham số URL, URL sẽ trở nên quá dài và có thể chạm tới giới hạn độ dài của trình duyệt hoặc máy chủ
- Ký tự không phải ASCII hoặc ký tự đặc biệt cần được mã hóa, làm tăng kích thước yêu cầu
- Cách biểu diễn mảng hoặc cấu trúc lồng nhau chưa được tiêu chuẩn hóa (ví dụ: roles[]=admin vs roles=admin)
- Máy chủ/middleware ghi lại tham số URL vào log, nên có thể gây vấn đề khi truyền dữ liệu nhạy cảm
- Việc gửi phần thân yêu cầu trong GET không bị cấm rõ ràng trong đặc tả, nhưng do proxy/tường lửa/trình duyệt xử lý khác nhau nên trên thực tế hầu như không thể sử dụng
Vấn đề của việc lách bằng POST
- Có thể gửi phần thân yêu cầu, nhưng POST được định nghĩa là không idempotent, nên việc tự động thử lại khi thất bại là không an toàn
- Proxy hoặc middleware không thể nhận biết đây là thao tác chỉ đọc, nên không thể tối ưu như tự động cache
- Về mặt ngữ nghĩa, việc dùng POST vốn dành cho tạo/xử lý tài nguyên để phục vụ tìm kiếm là không phù hợp với nguyên tắc thiết kế RESTful
Phương thức QUERY
- Một phương thức HTTP mới, an toàn (safe) và idempotent như GET, đồng thời có thể chứa phần thân yêu cầu
- Có thể cache, nhưng khi triển khai cần đưa phần thân yêu cầu vào cache key, nên việc triển khai cache phức tạp hơn GET
- Tóm lại, mục tiêu cốt lõi là "thay thế POST trong các yêu cầu chỉ đọc"
Lưu ý
- Mức độ hỗ trợ QUERY của client/proxy/server hiện vẫn còn hạn chế, và có thể cần thời gian để được hỗ trợ đầy đủ
- Nếu tham số truy vấn GET đơn giản là đủ, thì không nhất thiết phải thay đổi
- Nếu cần chia sẻ URL hoặc bookmark cho dữ liệu đã lọc, thì GET vẫn phù hợp
6 bình luận
Ờ... họ không nghĩ tới chuyện trong khoảng 10 năm tới, phương thức QUERY vẫn có thể chưa được áp dụng trên từng proxy/tường lửa/trình duyệt khác nhau sao? Hay là họ đang nhìn xa tận tương lai vậy nhỉ.
Có vẻ là cái sau.
Tôi nhớ là từng có vấn đề với API dịch vụ của một công ty nào đó: dù nhận bằng POST nhưng nếu không truyền y hệt cả tham số URL thì nó sẽ không hoạt động.
Ở Hàn Quốc cũng khá hay có trường hợp người ta kiểu “PUT hay DELETE là cái gì vậy?”, nên không biết sẽ mất bao lâu nữa thì đến cả QUERY mới được chấp nhận rộng rãi.
??? : Đừng làm REST nữa, cứ thống nhất hết bằng POST đi
???: POST tốt cho bảo mật
Tài liệu RFC là https://datatracker.ietf.org/doc/rfc10008/ nhỉ.
GET có nhược điểm là URL sẽ dài ra, nhưng cũng có vẻ có ưu điểm là có thể chia sẻ nguyên trạng địa chỉ URL, như khi muốn chia sẻ kết quả của một bộ lọc truy vấn cụ thể trong ElasticSearch.
Có lẽ cũng có nhiều chỗ đang được dùng một cách ngầm định với tiền đề là yêu cầu GET được gõ vào thanh địa chỉ của trình duyệt, nên để ổn định phổ biến chắc sẽ cần khá nhiều thời gian ngoài cả mức hỗ trợ kỹ thuật.