Соберите собственную панель управления

Предлагаемый контракт версии один разделяет ресурсы каталога и ресурсы учётной записи. Локации и планы поддерживают конфигурацию. Услуги представляют принятые конфигурации и состояние выполнения. Биллинг содержит счета и состояние оплаты. Обращения поддерживают отслеживаемую переписку с поддержкой. Веб-сайт реализует собственные формы и рабочее пространство; приведённые ниже примеры — это проектный контракт, а не маршруты к публичному API.

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

GET /v1/services
Authorization: Bearer <private-token>
Accept: application/json

# Proposed scope: services:read

Используйте стабильный идентификатор для каждого ресурса и ID запроса для поддержки. Изменяющие вызовы должны принимать ключ идемпотентности, чтобы повтор можно было согласовать, а не создавать ещё один заказ.

POST /v1/services
Idempotency-Key: <one-key-per-request>

{
  "plan_id": "umbra-1",
  "location": "iceland",
  "billing_cycle": "monthly",
  "image": "Ubuntu"
}

Предлагаемые ограничения скорости на уровне учётной записи составляют 60 операций чтения в минуту и 20 операций записи в минуту с допустимым всплеском до удвоенных значений. Отклонённый запрос возвращает HTTP 429 с Retry-After; автоматизация должна ждать, как указано, и применять экспоненциальную задержку. Ошибки должны содержать стабильный код, понятное человеку сообщение и request_id, а конфиденциальные сведения должны быть удалены.

{
  "error": {
    "code": "unsupported_location",
    "message": "This plan is not listed in that region.",
    "request_id": "req_example"
  }
}

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

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

Приложение учётной записи имеет запросы на оплату по фиксированному адресу и истекающие котировки сервера USD. Наблюдение за транзакциями — это доверенная интеграция только на стороне сервера; нет публичной конечной точки подтверждения, подключённого монитора блокчейна или обработчика подготовки. Опрос из браузера читает существующее состояние оплаты вошедшего клиента и не может подтвердить транзакцию. Иллюстративный публичный API и контракт вебхука выше остаются будущей проектной работой.

• Защитите логику ограничения частоты и наблюдения на сервере.
• Связывайте повторно используемые адреса получения с проверенной транзакцией и явной ссылкой на заказ.
• Держите оплаченное и предоставленное раздельно; подтверждённая транзакция не должна создавать фиктивное оборудование.