Làm cách nào để giải quyết các giới hạn độ dài chuỗi truy vấn HTTP GET mà vẫn muốn RESTful?

Như đã nêu trong http://www.boutell.com/newfaq/misc/urllength.html , chuỗi truy vấn HTTP có độ dài giới hạn. Nó có thể bị giới hạn bởi máy khách (Firefox, IE, ...), máy chủ (Apache, IIS, ...) hoặc thiết bị mạng (tường lửa ứng dụng, ...).

Hôm nay tôi phải đối mặt với vấn đề này với một biểu mẫu tìm kiếm. Chúng tôi đã phát triển một biểu mẫu tìm kiếm với rất nhiều trường và biểu mẫu này được gửi đến máy chủ dưới dạng yêu cầu GET, vì vậy tôi có thể đánh dấu trang kết quả.

Chúng tôi có rất nhiều trường nên chuỗi truy vấn của chúng tôi dài 1100 byte và chúng tôi có tường lửa loại bỏ các yêu cầu HTTP GET với hơn 1024 byte. Quản trị viên hệ thống của chúng tôi khuyến nghị chúng tôi sử dụng POST để thay thế, vì vậy sẽ không có giới hạn.

Chắc chắn, POST sẽ hoạt động, nhưng tôi thực sự cảm thấy tìm kiếm là một NHẬN chứ không phải một ĐĂNG. Vì vậy, tôi nghĩ rằng tôi sẽ xem xét các tên trường của chúng tôi để đảm bảo chuỗi truy vấn không quá dài và nếu không thể, tôi sẽ thực dụng và sử dụng POST.

Nhưng có một lỗ hổng nào trong việc thiết kế các dịch vụ RESTful không? Nếu chúng tôi có độ dài giới hạn trong yêu cầu GET, tôi có thể làm thế nào để gửi các đối tượng lớn đến một dịch vụ web RESTful? Ví dụ, nếu tôi có một chương trình mà làm cho tính toán dựa trên một tập tin, và tôi muốn cung cấp một webservice RESTful như thế này: http://compute.com?content=<base64 file>. Điều này sẽ không hoạt động vì chuỗi truy vấn có độ dài không giới hạn.

Tôi hơi khó hiểu ...

Dựa trên mô tả của bạn, IMHO, bạn nên sử dụng ĐĂNG. POST là để đưa dữ liệu lên máy chủ và trong một số trường hợp, có được câu trả lời. Trong trường hợp của bạn, bạn thực hiện một tìm kiếm (gửi một truy vấn đến máy chủ) và nhận được kết quả của tìm kiếm đó (lấy kết quả truy vấn).

Định nghĩa của GET nói rằng nó phải được sử dụng để lấy một tài nguyên đã tồn tại. Theo định nghĩa, POST là tạo một tài nguyên mới. Đây chính xác là những gì bạn đang làm: tạo một tài nguyên trên máy chủ và truy xuất nó! Ngay cả khi bạn không lưu trữ kết quả tìm kiếm, bạn đã tạo một đối tượng trên máy chủ và truy xuất nó. Như PeterMmm đã nói trước, bạn có thể làm điều này với POST (tạo và lưu trữ kết quả truy vấn) và sau đó sử dụng GET để truy xuất lại truy vấn, nhưng thực tế hơn chỉ thực hiện POST và truy xuất kết quả.

Hi vọng điêu nay co ich! :)

Đặc tả HTTP thực sự khuyên bạn nên sử dụng POST khi gửi dữ liệu đến một tài nguyên để tính toán.

Tìm kiếm của bạn trông giống như một phép tính, không phải là một tài nguyên. Điều bạn có thể làm nếu vẫn muốn kết quả tìm kiếm của mình là một tài nguyên là tạo một mã thông báo để xác định kết quả tìm kiếm cụ thể đó và chuyển hướng tác nhân người dùng đến tài nguyên đó.

Sau đó, bạn có thể xóa mã kết quả tìm kiếm sau một khoảng thời gian.

Thí dụ

POST /search
query=something&category=c1&category=c2&...

201 Created
Location: /search/01543164876

sau đó

GET /search/01543164876

200 Ok
... your results here...

Bằng cách này, trình duyệt và proxy vẫn có thể lưu kết quả tìm kiếm vào bộ nhớ cache nhưng bạn đang gửi tham số truy vấn của mình bằng POST.

BIÊN TẬP

Để làm rõ, 01543164876ở đây đại diện cho một ID duy nhất cho tài nguyên đại diện cho tìm kiếm của bạn. 2 yêu cầu đó về cơ bản có nghĩa là: tạo một đối tượng tìm kiếm mới với các tiêu chí này, sau đó truy xuất các kết quả được liên kết với đối tượng tìm kiếm đã tạo.

ID này có thể là một ID duy nhất được tạo cho mỗi yêu cầu mới. Điều này có nghĩa là máy chủ của bạn sẽ bị rò rỉ các đối tượng "tìm kiếm" và bạn sẽ phải làm sạch chúng thường xuyên bằng chiến lược bộ nhớ đệm.

Hoặc nó có thể là một hàm băm của tất cả các tiêu chí tìm kiếm thực sự đại diện cho tìm kiếm mà người dùng yêu cầu. Điều này cho phép bạn sử dụng lại các ID vì việc tạo lại một tìm kiếm sẽ trả về một ID hiện có có thể (hoặc không) đã được lưu trong bộ nhớ cache.

REST là một cách để thực hiện mọi thứ, không phải là một giao thức. Ngay cả khi bạn không thích ĐĂNG khi nó thực sự là GET, nó vẫn hoạt động.

Nếu bạn sẽ / phải ở với định nghĩa "tiêu chuẩn" của GET, POST, v.v. có thể xem xét ĐĂNG một truy vấn, truy vấn đó sẽ được lưu trữ trên máy chủ với một id truy vấn và yêu cầu truy vấn sau với GET theo id.

Về ví dụ của bạn:, http://compute.com?content={base64file}tôi sẽ sử dụng POST vì bạn đang tải lên "một cái gì đó" được tính toán. Đối với tôi, "cái gì đó" giống như một tài nguyên hơn như một tham số đơn giản.

Ngược lại với điều này trong tìm kiếm thông thường, tôi sẽ bắt đầu gắn bó với GET và các tham số. Bạn giúp các ứng dụng khách có thể kiểm tra và chơi với api của bạn dễ dàng hơn rất nhiều. Làm cho quyền truy cập chỉ đọc (trong hầu hết các trường hợp là phần lớn lưu lượng truy cập) càng đơn giản càng tốt!

Nhưng vấn đề nan giải của các chuỗi truy vấn lớn là một hạn chế hợp lệ của GET. Ở đây tôi sẽ thực dụng, miễn là bạn không đạt đến giới hạn này, hãy sử dụng GET và url-params. Điều này sẽ hoạt động trong 98% các trường hợp tìm kiếm. Chỉ hành động nếu bạn đạt đến giới hạn này và sau đó cũng giới thiệu POST với tải trọng (với kiểu mime Content-Type: application/x-www-form-urlencoded).

Bạn có thêm ví dụ trong thế giới thực không?

Sự nhầm lẫn xung quanh GET là một hạn chế của trình duyệt. Nếu bạn đang tạo giao diện RESTful cho ứng dụng A2A hoặc P2P thì không có giới hạn về thời lượng GET của bạn.

Bây giờ, nếu bạn tình cờ muốn sử dụng trình duyệt để xem giao diện RESTful của mình (hay còn gọi là trong quá trình phát triển / gỡ lỗi) thì bạn sẽ gặp phải giới hạn này, nhưng vẫn có các công cụ để giải quyết vấn đề này.

Đây là một điều dễ dàng. Sử dụng POST. HTTP không áp đặt giới hạn về độ dài URL cho GET nhưng các máy chủ thì có. Hãy thực dụng và giải quyết vấn đề đó bằng BÀI ĐĂNG.

Bạn cũng có thể sử dụng phần thân GET (được phép) nhưng đó là một vấn đề kép ở chỗ nó không được sử dụng đúng cách và có thể sẽ gặp sự cố máy chủ.