Почніть зі схеми запитів
Плануючи бюджет обговорень офлайн-карт у туристичному застосунку, спершу зрозумійте: витрати залежать від запитів на отримання даних, а не від обсягу поверненого. Один успішний пошук коштує один кредит незалежно від того, повертає він три записи, 100 записів чи порожній список. Менша сторінка може покращити читання, але не зменшує кредитної ціни цього запиту.
Накресліть дії, які справді звертаються до сервісу. Перший пошук, запит наступної сторінки, явне оновлення й пошук окремого запису можуть бути самостійними зверненнями. Прокручування вже завантаженого тексту не є новим запитом. Одне натискання не обов’язково коштує один кредит, якщо бекенд розкладає його на кілька викликів.
Прорахуйте умовний день
Ось приклад планування, а не спостережений трафік чи прогноз використання: припустімо, застосунок виконав 120 запитів перших сторінок, 30 додаткових сторінок і 10 оновлень. Це 160 успішних запитів і 160 кредитів, що дорівнює $0.16 за вказаною ставкою. Якщо 20 перших відповідей порожні, підсумок залишається 160 кредитів, адже ці запити все одно успішні.
Тепер припустімо, що інтерфейс автоматично отримує три сторінки для кожного першого пошуку, навіть якщо їх ніхто не читає. Це дало б 360 запитів без урахування оновлень замість 150 перших і свідомо запитаних наступних сторінок у першому прикладі. Порівняння є арифметикою за заданих припущень, а не даними про реальних користувачів. Після реалізації замініть припущення власним виміряним журналом запитів.
Відокремте ціну від покупки
Стандартна ставка — $1 за 1000 успішних запитів даних. Мінімальне платне поповнення становить $50 і дає 50 000 платних кредитів. Підписки немає, платні кредити не мають строку дії. Тому гіпотетичний день за $0.16 описує споживання балансу, а не можливість поповнення на $0.16.
Необов’язкові 100 пробних кредитів залежать від спільних для мережі перевірок права на них і відокремлені від платної конвертації. Не припускайте, що їх отримує кожна реєстрація, і не представляйте функцію як безкоштовний API. Створіть рахунок після входу, а потім використайте точну суму до сплати, одержувача, токен і мережу. Кроки облікового запису й оплати наведені в розділі «Ключ і кредити».
Розрізняйте помилки та невизначеність
HTTP 400, 401, 402 і 429 відхиляються до резервування кредиту на отримання даних. Вони відповідно позначають неправильний ввід, відсутній або недійсний ключ, недостатньо кредитів і обмеження частоти. Невдалий запит до джерела звільняє резерв, хоча звіряння може залишатися незавершеним. Не описуйте всі помилки як негайне повернення попереднього списання.
Якщо застосунок утратив відповідь після надсилання запиту, він може не знати, чи сервер успішно отримав дані. Повтор — це інший запит, а не гарантовано безкоштовне продовження. Зафіксуйте невідомий результат, збережіть запитання й уникайте шквалу автоматичних повторів. Для звіряння в обліковому записі доступні лічильники успішних, очікуваних і повернених запитів.
Установіть межу для функції
Кожен пошук допускає сторінки 1–100 і щонайбільше 100 записів на запит. Це межі сервісу, а не рекомендація отримувати кожну сторінку. Застосунок може вибрати менший бюджет сторінок на сеанс читання й запитувати згоду перед подальшим отриманням. Зважайте на pagination.has_more та кінцеву межу вікна, а не шукайте порожню сторінку повторними зверненнями.
Не вважайте потенційне вікно в 10 000 записів гарантованим обсягом результату. Відповідь може бути порожньою, у записів можуть бути відсутні поля, а архів не обіцяє повноти охоплення. /v1/status не тарифікується, але не повертає балансу й не перевіряє справності пошуку. Локальні лічильники також потребують звіряння: вони не доводять, що втрачений запит був безкоштовним.
Перегляньте дії, які справді потрібні читачеві
Для запропонованої туристичної панелі короткої першої сторінки та свідомої дії «Показати ще» може вистачити для порівняння посилань на обговорення. Зберігайте або відкривайте наявний вміст застосунку без прихованого повторного отримання. Якщо читач явно просить перевірити запис ще раз, поясніть, що це новий пошук, і обробіть недоступний результат.
Вирішуйте, чи потрібна зміна меж або подання, на основі власних даних трафіку. Не перетворюйте приклад планування на обіцяну вартість на користувача, показник утримання або тест продуктивності. У /uk/#field-notes описані обмежена пагінація та проєктування локального списку читання.
