Phân trang trong ứng dụng web REST

Đây là một cải cách chung hơn cho câu hỏi này (với việc loại bỏ các phần cụ thể của Rails)

Tôi không chắc chắn cách triển khai phân trang trên tài nguyên trong ứng dụng web RESTful. Giả sử rằng tôi có một tài nguyên được gọi products, bạn nghĩ cách nào sau đây là cách tiếp cận tốt nhất và tại sao:

1. Chỉ sử dụng chuỗi truy vấn

ví dụ. http://application/products?page=2&sort_by=date&sort_how=asc
Vấn đề ở đây là tôi không thể sử dụng bộ nhớ đệm toàn trang và URL cũng không rõ ràng và dễ nhớ.

2. Sử dụng các trang làm tài nguyên và chuỗi truy vấn để sắp xếp

ví dụ. http://application/products/page/2?sort_by=date&sort_how=asc
Trong trường hợp này, vấn đề được nhìn thấy là đó http://application/products/pages/1không phải là một tài nguyên duy nhất vì việc sử dụng sort_by=pricecó thể mang lại một kết quả hoàn toàn khác và tôi vẫn không thể sử dụng bộ đệm ẩn trang.

3. Sử dụng các trang làm tài nguyên và phân đoạn URL để sắp xếp

ví dụ. http://application/products/by-date/page/2
Cá nhân tôi thấy không có vấn đề gì khi sử dụng phương pháp này, nhưng ai đó đã cảnh báo tôi rằng đây không phải là cách hay (anh ấy không đưa ra lý do, vì vậy nếu bạn biết tại sao nó không được khuyến nghị, vui lòng cho tôi biết)

Bất kỳ đề xuất, ý kiến, phê bình đều được chào đón. Cảm ơn.

Tôi nghĩ vấn đề với phiên bản 3 là vấn đề "quan điểm" hơn - bạn có thấy trang này là tài nguyên hoặc sản phẩm trên trang không.

Nếu bạn xem trang là tài nguyên thì đó là một giải pháp hoàn toàn tốt, vì truy vấn cho trang 2 sẽ luôn mang lại trang 2.

Nhưng nếu bạn thấy các sản phẩm trên trang là tài nguyên bạn gặp phải vấn đề thì các sản phẩm trên trang 2 có thể thay đổi (sản phẩm cũ đã bị xóa hoặc bất cứ điều gì), trong trường hợp này, URI không phải lúc nào cũng trả lại cùng một tài nguyên.

Ví dụ: Một khách hàng lưu trữ một liên kết đến trang danh sách sản phẩm X, lần tiếp theo liên kết được mở sản phẩm được đề cập có thể không còn trên trang X.

Tôi đồng ý với Fionn, nhưng tôi sẽ tiến thêm một bước và nói rằng với tôi Trang không phải là tài nguyên, đó là tài sản của yêu cầu. Điều đó khiến tôi chỉ chọn tùy chọn 1 chuỗi truy vấn. Nó chỉ cảm thấy đúng. Tôi thực sự thích cách Twitter API được cấu trúc một cách yên tĩnh. Không quá đơn giản, không quá phức tạp, tài liệu tốt. Dù tốt hay xấu thì đó là thiết kế "đi đến" của tôi khi tôi ở trên hàng rào để làm một việc gì đó theo cách này so với cách khác.

HTTP có tiêu đề Phạm vi tuyệt vời cũng phù hợp để phân trang. Bạn có thể gửi

Range: pages=1

chỉ có trang đầu tiên Điều đó có thể buộc bạn phải suy nghĩ lại về một trang. Có thể khách hàng muốn một loạt các mặt hàng khác nhau. Tiêu đề phạm vi cũng hoạt động để khai báo một đơn đặt hàng:

Range: products-by-date=2009_03_27-

để có được tất cả các sản phẩm mới hơn ngày đó hoặc

Range: products-by-date=0-2009_11_30

để có được tất cả các sản phẩm cũ hơn ngày đó. '0' có lẽ không phải là giải pháp tốt nhất, nhưng RFC dường như muốn một cái gì đó để bắt đầu phạm vi. Có thể có các trình phân tích cú pháp HTTP được triển khai mà sẽ không phân tích đơn vị = -range_end.

Nếu các tiêu đề không phải là một tùy chọn (chấp nhận được), tôi nghĩ giải pháp đầu tiên (tất cả trong chuỗi truy vấn) là một cách để xử lý các trang. Nhưng xin vui lòng, bình thường hóa các chuỗi truy vấn (sắp xếp (key = value) theo thứ tự bảng chữ cái). Điều này giải quyết vấn đề phân biệt "? A = 1 & b = x" và "? B = x & a = 1".

Tùy chọn 1 có vẻ tốt nhất, đến mức mà ứng dụng của bạn xem phân trang là một kỹ thuật để tạo ra một chế độ xem khác nhau cho cùng một tài nguyên.

Phải nói rằng, lược đồ URL tương đối không đáng kể. Nếu bạn đang thiết kế ứng dụng của mình theo định hướng siêu văn bản (vì tất cả các ứng dụng REST phải theo định nghĩa), thì máy khách của bạn sẽ không tự mình xây dựng bất kỳ URI nào. Thay vào đó, ứng dụng của bạn sẽ cung cấp các liên kết cho khách hàng và khách hàng sẽ theo dõi họ.

Một loại liên kết mà khách hàng của bạn có thể cung cấp là liên kết phân trang.

Tác dụng phụ dễ chịu của tất cả những điều này là ngay cả khi bạn thay đổi suy nghĩ về cấu trúc URI phân trang và thực hiện một cái gì đó hoàn toàn khác vào tuần tới, khách hàng của bạn có thể tiếp tục làm việc mà không cần sửa đổi gì.

Tôi đã luôn sử dụng kiểu tùy chọn 1. Bộ nhớ đệm không phải là vấn đề đáng lo ngại vì dữ liệu thay đổi thường xuyên trong trường hợp của tôi. Nếu bạn cho phép kích thước của trang có thể định cấu hình thì một lần nữa dữ liệu không thể được lưu vào bộ nhớ cache.

Tôi không tìm thấy url khó nhớ hoặc ô uế. Đối với tôi đây là một sử dụng tốt các tham số truy vấn. Tài nguyên rõ ràng là một danh sách các sản phẩm và các tham số truy vấn chỉ cho biết cách bạn muốn danh sách được hiển thị - được sắp xếp và trang nào.

Điều kỳ lạ là không ai chỉ ra rằng Tùy chọn 3 có các tham số theo một thứ tự cụ thể. http // ứng dụng / sản phẩm / Ngày / Giảm dần / Tên / Tăng dần / trang / 2 và http // ứng dụng / sản phẩm / Tên / Tăng dần / Ngày / Giảm dần / trang / 2

đang trỏ đến cùng một tài nguyên, nhưng có các url hoàn toàn khác nhau.

Đối với tôi, Lựa chọn 1 có vẻ dễ chấp nhận nhất, vì nó phân tách rõ ràng "Điều tôi muốn" và "Tôi muốn như thế nào" (Nó thậm chí còn có dấu hỏi giữa chúng lol). Bộ nhớ đệm toàn trang có thể được triển khai bằng URL đầy đủ (Tất cả các tùy chọn sẽ chịu cùng một vấn đề).

Với cách tiếp cận Tham số trong URL, lợi ích duy nhất là URL sạch. Mặc dù bạn phải nghĩ ra một số cách để mã hóa các tham số và giải mã chúng một cách dễ dàng. Tất nhiên bạn có thể đi với URLencode / giải mã, nhưng nó sẽ làm cho url trở nên xấu xí một lần nữa :)

Tôi muốn sử dụng các tham số truy vấn bù và giới hạn.

offset : cho chỉ mục của mục trong bộ sưu tập.

giới hạn : cho số lượng mặt hàng.

Khách hàng có thể tiếp tục cập nhật phần bù như sau

offset = offset + limit

cho trang tiếp theo.

Đường dẫn được coi là định danh tài nguyên. Và một trang không phải là tài nguyên mà là tập hợp con của bộ sưu tập tài nguyên. Vì phân trang nói chung là một yêu cầu GET, các tham số truy vấn phù hợp nhất cho phân trang hơn là các tiêu đề.

Tham khảo: https://metamug.com/article/rest-api-developers-dilemma.html#Requesting-the-next-page

Tìm kiếm các thực tiễn tốt nhất tôi đã xem qua trang web này:

http://www.restapitutorial.com

Trong trang tài nguyên có một liên kết để tải xuống .pdf có chứa các thực tiễn tốt nhất REST hoàn chỉnh được đề xuất bởi tác giả. Trong đó trong số những thứ khác có một phần về phân trang.

Tác giả đề nghị thêm hỗ trợ cho cả hai bằng cách sử dụng tiêu đề Phạm vi và sử dụng tham số chuỗi truy vấn.

Yêu cầu

Ví dụ tiêu đề HTTP:

Range: items=0-24

Ví dụ về tham số chuỗi truy vấn:

GET http://api.example.com/resources?offset=0&limit=25

Trong đó offset là số mục bắt đầu và giới hạn là số mục tối đa được trả về.

Phản ứng

Phản hồi phải bao gồm tiêu đề Phạm vi Nội dung cho biết có bao nhiêu mục đang được trả lại và tổng số mục tồn tại chưa được truy xuất

Ví dụ tiêu đề HTTP:

Content-Range: items 0-24/66

Content-Range: items 40-65/*

Trong .pdf có một số gợi ý khác cho các trường hợp cụ thể hơn.

Tôi hiện đang sử dụng một lược đồ tương tự như thế này trong các ứng dụng ASP.NET MVC của mình:

ví dụ http://application/products/by-date/page/2

cụ thể là: http://application/products/Date/Ascending/3

Tuy nhiên, tôi không thực sự hài lòng với việc bao gồm phân trang và sắp xếp thông tin trong tuyến đường theo cách này.

Danh sách các mặt hàng (sản phẩm trong trường hợp này) là có thể thay đổi. tức là lần sau khi ai đó quay lại url bao gồm các tham số phân trang và sắp xếp, kết quả họ nhận được có thể đã thay đổi. Vì vậy, ý tưởng về http://application/products/Date/Ascending/3một url duy nhất trỏ đến một bộ sản phẩm được xác định, không thay đổi sẽ bị mất.

Tôi có xu hướng đồng ý với slf rằng "trang" không thực sự là một tài nguyên. Mặt khác, tùy chọn 3 sạch hơn, dễ đọc hơn và người dùng có thể dễ dàng đoán ra hơn và thậm chí có thể gõ ra nếu cần thiết. Tôi bị giằng xé giữa tùy chọn 1 và 3, nhưng không thấy lý do nào để không sử dụng tùy chọn 3.

Ngoài ra, trong khi chúng trông đẹp mắt, một nhược điểm của việc sử dụng các tham số ẩn, như ai đó đã đề cập, thay vì các chuỗi truy vấn hoặc phân đoạn URL là người dùng không thể đánh dấu hoặc liên kết trực tiếp đến một trang cụ thể. Điều đó có thể hoặc không thể là một vấn đề tùy thuộc vào ứng dụng, nhưng chỉ cần một cái gì đó để nhận biết.

Tôi đã sử dụng giải pháp 3 trước đây (tôi viết RẤT NHIỀU ứng dụng django). Và tôi không nghĩ rằng có bất cứ điều gì sai với nó. Nó cũng hào phóng như hai cái kia (trong trường hợp bạn cần phải thực hiện một số thao tác cạo hàng loạt hoặc tương tự) và nó trông sạch sẽ hơn. Ngoài ra, người dùng của bạn có thể đoán các url (nếu là ứng dụng công khai) và mọi người thích có thể đi trực tiếp đến nơi họ muốn và việc đoán url cảm thấy có sức mạnh.

Tôi sử dụng trong các dự án của mình các url sau:

http://application/products?page=2&sort=+field1-field2

có nghĩa là - "hãy cho tôi trang thứ hai được sắp xếp tăng dần theo trường1 và sau đó giảm dần theo trường2". Hoặc nếu tôi cần linh hoạt hơn nữa, tôi sử dụng:

http://application/products?skip=20&limit=20&sort=+field1-field2

Tôi sử dụng trong các mẫu sau để có được bản ghi trang tiếp theo. http: // application / sản phẩm? lastRecordKey =? & pageSize = 20 & sort = ASC

RecordKey là cột của bảng chứa giá trị tuần tự trong DB. Điều này được sử dụng để chỉ tìm nạp một dữ liệu trang tại DB. pageSize được sử dụng để xác định số lượng bản ghi cần tìm nạp. sort được sử dụng để sắp xếp bản ghi theo thứ tự tăng dần hoặc giảm dần.