Концепция

Модель платформы

ZennoHosting организован вокруг проектов и их дочерних ресурсов. Если изначально моделировать API как project-first систему, поведение платформы становится предсказуемым: provisioning inputs отделяются от runtime resources, а follow-up operations остаются в scope одного и того же проекта.

Provisioning inputs

Images

Определяют базовую ОС или machine template, используемые при создании VM.

VM Tariffs

Определяют коммерческий профиль самой виртуальной машины.

Configurations

Показывают доступные профили конфигурации VM, которые можно использовать при выборе.

Access and Plugins

Доступ можно передавать как raw public keys или existing SSH key IDs, а optional plugins можно добавить на этапе provisioning.

Runtime resources

Projects

Верхнеуровневый scope для VM, SSH-ключей, сетей, public IP и backup.

VMs

Основной compute resource. Ответы VM содержат идентификаторы, размеры ресурсов и сетевые подключения.

Networks

Project-level network resources, к которым VM можно подключать и перенастраивать.

Public IPs and Backups

Public IP являются project-level ресурсами, а backup — VM-scoped точками восстановления, управляемыми под конкретной VM.

Project-first границы

Сначала создавайте проект, и только потом SSH keys, networks, public IP и VM.
Храните projectId как первичный идентификатор в клиентской модели.
Переиспользуйте project-scoped ресурсы вместо их ad hoc создания для каждой VM.
Не моделируйте lifecycle public IP как часть lifecycle private network. Они связаны, но различны.

Важные provisioning decisions

Корректный create VM payload зависит от live inputs. До вызова create определите образ, VM tariff и optional public IP behavior. Если вы запрашиваете новый public IP, помните, что public IP pricing — это отдельное решение, а не свойство VM tariff.

Рекомендация по моделированию

В клиентском коде воспринимайте projectId, vmId, networkId и publicIpId как стабильные ссылки. Это основные join keys почти для всех follow-up запросов в текущей API-поверхности.