Bug in SOAP/HostingSubscriptionEdit?

Meine Frage mal hier in den Raum geworfen, evtl. übersehe ich nur einen Parameter.

Auf einem Server wurden verschiedene Angebote (HostingPlanAdd) angelegt, die entsprechende Einstellungen definieren. Nun wurde ein Vertrag über SOAP mit "HostingSubscriptionAdd" angelegt und ein entsprechender "plan" übergeben.

Im Laufe der Zeit benötigt der Kunde z.B. etwas mehr Speicherplatz. Dieses kann ich mittels "HostingSubscriptionEdit" und "webspace" zuweisen. So weit so gut. Der Kunde wächst weiter und wünscht generell mehr Leistungsumfang. Ergo weise ich ihm mit "HostingSubscriptionEdit" einen neuen "Plan" zu, der diese Leistungen enthält. Mein Gedanke, somit stelle ich das gesamte Paket auf den neuen Leistungsumfang ein.

Leider falsch gedacht. LiveConfig übernimmt zwar die neuen Einstellungen des geänderten Plans, der zuvor einzeln abgeänderte Punkt "webspace" behält jedoch weiterhin die vom vorherigen Plan abweichende Einstellung.

Ist dieses Verhalten ein Fehler? Oder habe ich hier etwas übersehen? Meine Erwartung wäre gewesen, dass LiveConfig bei Angabe eines neuen Plans ohne weitere Einzel-Übergaben auch die vorgegeben Werte des Plans verwendet. Das aktuelle Verhalten ist in meinen Augen unsinnig bzw. kontraproduktiv.
Sinn würde so ein Verhalten nur machen, wenn damit ein "Downgrade" vermieden werden soll.

Zitat von Marco

Sinn würde so ein Verhalten nur machen, wenn damit ein "Downgrade" vermieden werden soll.

Wie ich schon sagte, der Weg zurück (also geringerer Wert) kann gerne gesperrt sein.

Wie man es letztlich löst, ist eigentlich nebensächlich. Ein Schalter, über eine interne Regel oder wie auch immer. Unhaltbar ist jedoch der Umstand, das es eben keinen Weg zurück gibt. Einmal einen Wert gesetzt, blockiere ich alle Zugriffe.

Mir geht es auch nicht um eine Möglichkeit, über SOAP eine Verwaltungsoberfläche für ein Verwaltungspanel zu erschaffen. Aber jeder, der ernsthaft Hosting betreibt, hat irgendeine Art von Kundenverwaltung in Betrieb, die über ein Excel-Sheet hinausgeht. Und dafür fehlen etliche Funktionen in der SOAP-API, um dies sinnvoll einzubinden. Für mich sieht diese API so aus, als ob sie mit der heißen Nadel gestrickt wurde, um eine Migration von Confixx zu ermöglichen. Nicht mehr und nicht weniger unterstützt diese API.

Und über CURL ein System zu stricken, das die Weboberfläche malträtiert, macht keinen Sinn, wenn man eine API ausbauen kann/würde.