Đáp ứng đúng với yêu cầu HTTP khi yêu cầu quá nhiều dữ liệu

Tôi đang xây dựng API cho nền tảng phân phát quảng cáo cho phép bạn yêu cầu dữ liệu theo dõi cho các chiến dịch quảng cáo. Chiến dịch thường vượt quá hàng trăm triệu yêu cầu, điều đó có nghĩa là sẽ có nhiều dữ liệu trị giá hàng terabyte. Do đó, chúng tôi cần ngăn người tiêu dùng API yêu cầu quá nhiều dữ liệu cùng một lúc (chẳng hạn như yêu cầu hết thời gian), nhưng tôi không chắc cách thực hành tốt nhất để làm như vậy là gì.

Các tùy chọn tôi đã xác định là:

1. thêm một tham số phụ vào yêu cầu cho biết phần nào của dữ liệu là mong muốn
2. cắt bớt dữ liệu và bằng cách nào đó nói với khách hàng rằng họ cần sử dụng các bộ lọc cụ thể hơn
3. phản hồi với mã trạng thái HTTP 413 (nhưng điều này dường như dành cho các cơ quan yêu cầu lớn, không phải phản hồi)
4. chuyển sang API phát trực tuyến (như API phát trực tuyến của twitter )

Nhưng câu hỏi của tôi là, thực hành tiêu chuẩn / phản ứng thích hợp cho loại tình huống này là gì?

Lưu ý: Các cuộc tấn công DoS không phải là vấn đề đáng lo ngại vì đây sẽ không phải là API công khai

Trả về kết quả khắc nghiệt nhất, không thân thiện nhất có thể trong trường hợp yêu cầu không đúng định dạng (yêu cầu trả về nhiều dữ liệu hơn mức cho phép đo sáng của bạn là không đúng). Tôi đề nghị trả lại mã lỗi 4 **. Sau đó, cũng cung cấp các tham số phân trang, để người dùng có thể yêu cầu các trang. oData có tính năng này, ví dụ. Không được cắt dữ liệu trong âm thầm, trong mọi trường hợp.

Tư vấn với khách hàng là một ý tưởng tồi. Họ sẽ bảo bạn làm bất cứ điều gì có thể để giảm thiểu sai sót, đó là một cách tiếp cận kỹ thuật tồi. Đây là quyết định của bạn, lấy nó bằng sừng và làm điều đúng đắn.

Một ví dụ về api được phân trang là oData:

http://www.odata.org/documentation/odata-version-2-0/uri-conventions/

Để mở rộng những gì @ joshin4colours đã nói, tôi nghĩ bạn có sự phân đôi giả (trichotomy?). Tại sao không cung cấp cả ba giải pháp? Có thể mặc định là trả về 413 nhưng với các cờ khác, bạn có thể nhận được một số thứ bạn muốn với lỗi được nhúng trong dữ liệu và / hoặc cung cấp cách trộn dữ liệu.

Nó thực sự phụ thuộc vào những gì khách hàng / người tiêu dùng cụ thể của API mong đợi và cách họ muốn sử dụng API của bạn. Họ có bao giờ muốn có 413 không? Phản hồi mặc định có nên bao gồm một số dữ liệu và cho biết có bao nhiêu nữa không? Có lẽ. Bạn cũng có thể đặt mình vào vị trí của khách hàng và suy nghĩ về những gì họ muốn, tức là những gì sẽ hữu ích cho họ.

Những gì tôi thường làm là đưa ra lô dữ liệu đầu tiên với ý tưởng là còn bao nhiêu nữa. Trả lại 413 không thân thiện lắm, nhưng có thể đó là điều bạn muốn trong một số trường hợp. Từ những gì tôi đã trải nghiệm, thường có kích thước lô mặc định nhưng mọi người có thể yêu cầu một kích thước lô nhất định đến một số giới hạn.

Ngoài ra, bạn có thể xem xét tổng hợp hoặc lấy mẫu để giảm kích thước lô. Ví dụ: tôi muốn 50.000 kết quả dưới dạng mẫu ngẫu nhiên 5.000.000 hồ sơ phù hợp. Có nhiều cách khác nhau để cắt và xúc xắc tùy thuộc vào mức độ có ý nghĩa thống kê mà bạn muốn kết quả của mình đạt được.

Không chắc chắn về một thực tiễn tốt nhất, nhưng trong trường hợp của chúng tôi, chúng tôi có các tham số trong API được đặt thành một loại giá trị tối đa (nghĩ rằng Integer.MAX_VALUE từ Java). Các tham số này thường không có sẵn cho phía UI / máy khách của ứng dụng, chỉ cho các cuộc gọi phía máy chủ.

Về cơ bản, cách tiếp cận sẽ là thiết lập tối đa các hồ sơ được trả về theo yêu cầu của bạn. Có vẻ như hoạt động tốt, đặc biệt là khi dữ liệu không cần phải được tổ chức hoặc phân trang theo bất kỳ cách nào.

Nếu một khách hàng (con người hoặc người khác) cần nhiều hơn mức tối đa này, bạn có thể muốn xem xét tăng nó hoặc bó dữ liệu của bạn bằng cách nào đó.