Перейти к основному содержимому

Архитектура и формат ответов

Архитектура платформы ShopStory

Хост и версии​

  • Базовый хост: https://app.shopstory.live
  • Версии:
    • /v2 — mini-player сценарии
    • /v3 — каталог стримов и quick-state

Единый конверт ответа​

Почти все ответы возвращаются в конверте:

{
  "status": 200,
  "serverTime": "2026-02-24T14:20:02.34382755Z",
  "body": {}
}

Поля:

  • status — бизнес-статус внутри payload.
  • serverTime — серверное время (UTC, ISO 8601).
  • body — данные или ошибка.

HTTP-коды и status внутри конверта​

Ключевой момент: у разных endpoint разное поведение.

/v3/*​

Для валидационных ошибок часто возвращается HTTP 200, а ошибка лежит в status внутри конверта.

Пример (/v3/streams без applicationId):

{
  "status": 400,
  "body": {
    "error": "invalid",
    "message": "invalid applicationId"
  }
}

/v2/mini-player/stream​

Может возвращать и обычные HTTP ошибки (например 400/404) вместе с конвертом.

Пример (нет productCode и feedProductId):

{
  "status": 400,
  "body": {
    "error": "invalid",
    "message": "Bad request: either 'productCode' or 'feedProductId' must be provided"
  }
}

Вывод: всегда проверяйте оба уровня — HTTP-код и поле status в JSON.

Идентификаторы​

  • id, feedProductId, feedProductGroupId, vendorCode часто приходят строками.
  • Не приводите их принудительно к числам.

Аутентификация​

Production-модель: applicationId в query.

GET /v3/streams?applicationId=your-app-id&limit=10

Bearer-токены остаются закрытой бетой. Детали — в Authentication.

Практический контракт для клиента​

  1. Парсить envelope { status, serverTime, body }.
  2. Проверять HTTP-код отдельно.
  3. Закладывать tolerant parsing для body.error (может быть строкой, а не объектом).

Следующий шаг: Quickstart.

Последнее обновление