Руководство по мобильному AI API для разработчиков | OdiRouter

Редакция OdiRouter

Функция мобильного API ИИ должна предоставлять пользователям полезные результаты без необходимости размещения учетных данных поставщика или бизнес-правил в пакете приложения. Телефон запускает интерфейс. Ваш бэкенд проверяет запрос, применяет правила продукта и обращается к AI-сервису. Такое разделение позволяет менять модели, улучшать обработку сбоев и держать конфиденциальные значения под контролем сервера.

На публичном сайте OdiRouter описывается ориентированная на разработчиков платформа для API-интерфейсов моделей, выполнения агентов и GPU-нагрузок. На странице с ценами командам предлагается сравнивать актуальные цены моделей и направлять запросы из одной учётной записи OdiRouter с учётом стоимости, скорости и доступности. Считайте эти страницы актуальными справочными источниками. Название модели или её цена не должны становиться постоянным предположением мобильного клиента.

Назначьте каждому слою чёткую роль

Мобильный клиент собирает входные данные, отклоняет пустой запрос, показывает ход выполнения и отображает ответ. Он не должен содержать долгосрочный ODIROUTER_API_KEY, решать, кому разрешено использовать платную операцию, или обращаться к провайдеру напрямую из распространяемого бинарного файла приложения.

Бэкенд — место для политик. Он может аутентифицировать пользователя приложения, проверять права или квоту, ограничивать размер запроса, добавлять контекст приложения и записывать безопасный идентификатор задачи. Он также выбирает текущую модель и отправляет запрос к API. Ответ провайдера возвращается в контролируемую вами систему, прежде чем попасть на устройство.

mobile app -> your backend -> OdiRouter API -> your backend -> mobile app

Начните с действия, которое можно будет проверить.

Выберите задачу с видимыми входными данными и результатом, который люди могут проверить. Предложение ответа службе поддержки, краткое описание или черновик подписи легче тестировать, чем запрос «сделать приложение умным». Определите, что отправляет пользователь, что возвращает приложение и что происходит, если ответ получен с опозданием, неполный или не подходит для следующего шага.

Если функция может повлиять на опубликованное сообщение, платёж или другое значимое действие, представляйте результат как черновик. Пусть человек проверит, отредактирует, отклонит или попробует еще раз. Образец ответа может помочь в рабочем процессе, но это не означает разрешения на продолжение работы.

Выполняйте вызов OdiRouter на бэкенде

Исходный код текущей страницы OdiRouter содержит пример OpenAI Chat Completions по адресу https://api.odirouter.ai/v1/chat/completions с API-ключом Bearer. Приведённый ниже пример на Node.js показывает границу бэкенда. Он не обещает конкретную модель. Перед выбором идентификатора модели или переводом запроса в продакшен проверьте актуальные OdiRouter model catalog, pricing page и getting-started documentation.

export async function createMobileDraft(req, res) {
  const prompt = String(req.body?.prompt || "").trim();

  if (!prompt) {
    return res.status(400).json({ error: "A prompt is required." });
  }

  const response = await fetch(
    "https://api.odirouter.ai/v1/chat/completions",
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        Authorization: `Bearer ${process.env.ODIROUTER_API_KEY}`
      },
      body: JSON.stringify({
        model: "YOUR_CURRENT_MODEL_ID",
        messages: [{ role: "user", content: prompt }]
      })
    }
  );

  if (!response.ok) {
    return res.status(502).json({ error: "The AI request could not be completed." });
  }

  return res.json(await response.json());
}

Пример намеренно сделан небольшим. Для производственного маршрута по-прежнему необходимы ваши механизмы аутентификации, авторизации, ограничения запросов, политика логирования и формат ответа, с которым может работать мобильный интерфейс. Делайте текст ошибок полезным для человека, использующего приложение. Храните сведения о провайдере и инфраструктуре в серверных журналах.

Планируйте состояния мобильного интерфейса до проработки идеального сценария

Сетевые условия различаются. Операция ИИ может занять больше времени, чем обычная отправка формы, и пользователь может покинуть экран до её завершения. Предусмотрите в интерфейсе понятные состояния:

  • Готово: Объясните, что делает запрос и какие входные данные ему нужны.

  • Отправка: Отключите действие или безопасно исключите его дублирование, пока запрос запускается.

  • Выполняется: Покажите, что запрос активен, и, если продукт это поддерживает, предоставьте пользователям безопасный способ вернуться позже.

  • Завершено: Представьте контент, подлежащий проверке, с четким указанием дальнейших действий.

  • Сбой: Предложите простой способ повторной попытки, не раскрывая учетные данные или внутренние сведения о службе.

Если предусмотрена возможность отмены, передайте запрос или идентификатор задания через клиентскую часть и бэкэнд. Если доступна повторная попытка, определите, повторяет ли она запрос или возобновляет существующую задачу. Это решения, касающиеся самого продукта, а не настройки по умолчанию для мобильного SDK.

Следите за актуальностью выбранной модели.

Доступность моделей, цены и сведения о возможностях меняются. Храните выбор на сервере и фиксируйте соответствующий вариант вместе с задачей. Перед развёртыванием изучите актуальные варианты в OdiRouter model catalog и текущие pricing. Протестируйте мобильную задачу, которую планируете поддерживать, включая размер входных данных, состояния сбоев и процесс проверки.

Не обещайте мгновенных результатов или фиксированной стоимости, если это не подтверждается актуальными данными о конкретном продукте. Мобильная функция заслуживает доверия, когда она ясно сообщает о своём состоянии и даёт пользователям контроль над результатом.

Контрольный список перед выпуском

  • Храните ODIROUTER_API_KEY на сервере, а не в пакете приложения iOS или Android.

  • Проверяйте запрос до того, как он достигнет провайдера, и применяйте авторизацию пользователя и ограничения продукта на бэкенде.

  • Выбирайте актуальную модель из каталога и информации о ценах OdiRouter, а не полагайтесь на жёстко заданное маркетинговое утверждение.

  • Отображайте в мобильном интерфейсе состояния ожидания, завершения, сбоя и повторной попытки.

  • Считайте сгенерированный результат черновиком, если он может повлиять на значимое действие.

Создайте следующий тест с помощью OdiRouter

Начните с OdiRouter getting-started documentation, затем сравните актуальные model catalog и pricing, прежде чем выбирать модель для мобильной функции. Сохраняйте первую интеграцию ограниченной. Расширяйте её после того, как граница сервера и поведение продукта станут ясны.

Источники

#API ИИ для мобильных приложений OdiRouter#API для мобильного ИИ#интеграция ИИ в мобильные приложения