Можна попросити API про список заданого розміру й побачити, коли його було обрізано

Шість списків у зовнішньому API тепер приймають розмір, а кожен список прямо повідомляє, чи його було обрізано, замість того щоб виглядати повним.

Шість списків у зовнішньому API — зображення сесій, пекшоти, відео, товари, сценерії та моделі — відповідали цілим списком і не приймали розміру. На справжньому обліковому записі це означало один виклик, що повертає близько 1,8 мільйона символів. /presets був єдиним маршрутом, який приймав розмір, тож будь-яка інтеграція мусила пам'ятати, який маршрут є винятком.

Усі шість тепер приймають maxRecords. Виклик, який не вказує розміру, отримує рівно те саме, що отримував раніше, — ніщо з уже побудованого не змінює поведінки.

І кожен список тепер повідомляє, чи його було обрізано. Це важливіша половина, бо обійти її на боці клієнта було неможливо. Усі ці списки вже мали обмеження, і жоден про це не казав: коли обмеження спрацьовувало, відповідь усе одно мала статус 200, список усе одно виглядав повним, а count усе одно дорівнював його довжині. Обрізаний список, який виглядає повним, — це список, який інтеграція вважає повним: вона робить висновок, що товару немає, що зображення ніколи не було створено, що замовлення нічого не дало, і ніщо у відповіді не позначає цей висновок як ненадійний.

Кожна відповідь зі списком тепер містить truncated. Ключ присутній завжди і має значення false, коли список повний, тож на нього можна покладатися, не перевіряючи, чи він узагалі є. count зберігає своє значення — кількість рядків у відповіді — і не є цим сигналом: на насиченому списку він може перевищувати межу, тоді як truncated має значення «істина».

Рядки, які ви отримуєте в обрізаному списку, — це найновіші відповідні рядки, а не довільна підмножина, і це справджується навіть тоді, коли читання під ним охоплює більш ніж одну сторінку.

Список відео приєднується до решти контентної поверхні. Він тепер враховує заголовок облікового запису, від імені якого ви дієте, так само як сусідні маршрути.