KeyHelp API [GELÖST]

[Jolinar]

Schön wäre es, wenn zumindestens dieser Weg dokumentiert werden würde

Das bekommst du aber mit ein paar Klicks im Panel und einigen CLI-Befehlen auch selbst hin...
- am CLI einen DB-Dump machen
- im Panel die gewünschte Aktion ausführen
- am CLI einen weiteren DB-Dump machen
- ein Diff über die beiden Dumps machen
- die Veränderungen analysieren und entsprechend in deine selbstgeschriebene API integrieren

[alex9849]

Gibt es mittlerweile bezüglich einer geplanten API etwas neues?

[Jolinar]

Gibt es mittlerweile bezüglich einer geplanten API etwas neues?

Nein.
Vor etwa zwei Wochen wurde die Version 19 ausgerollt, siehe hier: https://www.keyhelp.de/changelog/

[alex9849]

Wäre halt schön wenn man von offizieller Seite etwas dazu hören würde. Ob sowas geplant ist und wenn ja wann man damit rechnen kann.
Die Option die ganzen Änderungen an der Datenbank selbst vorzunehmen ist halt heikel. Da weiß man halt nicht ob das nach einem Update noch funktioniert und muss erstmal alles vor dem updaten gründlich testen.

[Jolinar]

Wäre halt schon wenn man von offizieller Seite ewas dazu hören würde. Ob sowas geplant ist und wenn ja wann man damit rechnen kann.

Wenn die Dev's es für notwendig bzw. sinnvoll halten, werden sie sich dazu sicher auch äußern...Und bis dahin werden sie ihrer Kerntätigkeit nachgehen und das Panel weiterentwickeln.
Bei den bisherigen Rollouts war stets zu beobachten, daß Bugfixing und Implementation neuer (und notwendiger) Features oberste Priorität hatten.
Wenn eine API auf der ToDo-Liste steht, dann wird sie auch kommen und es wird rechtzeitig vorher kommuniziert werden.

[OlliTheDarkness]

Ich grabe den Beitrag mal wieder aus und eröffne mal eine Spekulationsrunde .

viewtopic.php?f=9&p=17480&sid=c966c91d8 ... 304#p17480

Der letzte Absatz klingt doch irgendwie danach das Eure Wünsche erhört wurden.

[Enigma]

Der letzte Absatz klingt doch irgendwie danach das Eure Wünsche erhört wurden.

Das wäre absolut großartig, aber ich werde vorsichtshalber nicht die Luft anhalten, bis es eine API gibt.

Gruß
Jan

[Tobi]

Uh.
Alexander befreit mich von Migräne.

Müssen wir ihn jetzt mit "Doktor Alexander" ansprechen?

[Alexander]

Anbei die Referenz zur kommenden API, schaut mal drüber, ob noch was fehlt - Feedback ist willkommen (Logik-Fehler / Inkonsiztenzen / Rechtschreibfehler usw.). An Endpunkten würde ich es für den Initialen Release erst einmal so belassen.

https://app.swaggerhub.com/apis-docs/keyhelp/api


("Hosting plans" sind die Account-Templates)

[MLan]

schaut mal drüber..

Zu DKIM und DNS hab ich nichts gefunden.
Wäre sicherlich auch ganz brauchbar.

Gruß Mlan

[Tobi]

Feedback ist willkommen

Erstmal ein dickes WOW von mir. Das sieht ja schon sehr ausgereift und umfangreich aus. Vielen Dank für deine Arbeit

schaut mal drüber, ob noch was fehlt

Ich habe gesehen, dass man neue Kunden mit einem Hostingplan anlegen kann. Dazu ist mir aufgefallen, dass der Hosting Plan mit Namen benannt sein muss. Währe hier nicht die ID "robuster"?

Ebenso kann man dem Kunden dann eine Domain zuordnen. Im Hostingbusiness ist es aber gang und gäbe, dass der Kunde nicht nur ein Hostingpaket sondern auch gleich die Domain ordert.
Daher meine Frage nach einer Vereinfachung des Vorgangs. Wäre es möglich bei der Bestellung gleich den Domainnamen zu "übergeben", so dass die Bestellung in einem Rutsch ausgeführt wird?

Ebenso wäre eine Prüfung auf "Domainnamen bereits vergeben" mit gleichzeitiger Auth-Code Übermittlung auch _sehr_ wichtig.

[Enigma]

Zunächst einmal vielen Dank, das sieht schon klasse aus!

Ich habe gesehen, dass man neue Kunden mit einem Hostingplan anlegen kann. Dazu ist mir aufgefallen, dass der Hosting Plan mit Namen benannt sein muss. Währe hier nicht die ID "robuster"?

Ich bin geneigt, Tobi da zuzustimmen.

Da nach Rechtschreibfehlern gefragt wurde: Die API selbst ist, wenn ich nichts übersehen habe, fehlerfrei. In die Beschreibungen haben sich ein paar kleine Fehler eingeschlichen (einer mehrfach, nämlich "hosting-plan" - hier steht im Englischen kein Bindestrich):

GET ​/server
Returns various server information. ["information" hat im Englischen keinen Plural]


POST ​/clients
To specify its account features, you should use a hosting plan, otherwise it's created with the default hosting plan.


GET ​/clients​/{id}​/stats
Returns the statistics of the client about its assigned resources and their usage.


GET ​/hosting-plans
Returns a list of all hosting plans on the server.


GET ​/hosting-plans​/{id}
Returns features of a single hosting plan specified by its ID.


GET ​/hosting-plans​/name​/{name}
Returns features of a single hosting plan specified by its name.


GET ​/emails​/{id}
Returns information of a single email account specified by its ID.


GET ​/emails​/email​/{name}
Returns information of a single email account specified by its email address.

Außerdem noch ein paar Anmerkungen:

1. Bei GET /domains, GET /emails etc. werden jeweils ein UTF-8-Name und ein Punycode-Name zurückgegeben. Es sollte bei den POST-Methoden zumindest angegeben werden, welcher Wert angegeben werden muss. Dies selbst angeben zu können, wäre natürlich auch eine Option.
    
2. Bei POST ​/emails vermisse ich zumindest die Angabe der Größe, der Weiterleitungs-Adressen und ob es sich um einen reinen Forwarder handelt.
    
3. PUT ​/emails​/{id}: Werden hier zukünftig weitere Änderungsmöglichkeiten hinzugefügt? Funktioniert das Hinzufügen von Aliassen unmittelbar nach dem Anlegen einer E-Mail-Adresse oder erst, wenn der Cronjob gelaufen ist? Falls Letzteres, sollte auch das direkt beim Anlegen möglich sein.

Gruß
Jan

[christian.john]

Tolle Sache

Ich würde mich freuen, wenn man
1. PHP-Versionen bei den Domains setzen kann.
2. Hostingpläne erstellen / Client-Konfigurationen einzeln updaten kann.

Danke und viele Grüße, Christian

[select name from me;]

Anbei die Referenz zur kommenden API, schaut mal drüber, ob noch was fehlt - Feedback ist willkommen (Logik-Fehler / Inkonsiztenzen / Rechtschreibfehler usw.). An Endpunkten würde ich es für den Initialen Release erst einmal so belassen.

Sehr geil! Vielen Dank. Das wird für mich sehr viele Baustellen lösen.

/server
utilization ist praktisch für ein eigenes Monitoring. Wie verhält sich disk_space, wenn mehrere Platten verbaut sind?
Würde es hier Sinn machen, die Auslastung der inoden mit auszugeben (df - i)? Je nach Anwendungsfall ist manchmal die Platte nicht voll, aber die inoden komplett belegt.

/domains
Für mich wäre es wichtig, bestehende SSL Zertifikate zu wählen.

Falls ich mir noch etwas wünschen darf.

A-Priorität: Für mich wäre es auch wichtig Datenbanken und FTP Accounts anlegen zu können.
B-Priorität: Wenn man die Einstellungen, die man auf einem neuen Server vornimmt, auch per API ausführen könnte, wäre das super.

[Alexander]

Ersteinmal vielen Dank für das Feedback soweit.

Ich habe gesehen, dass man neue Kunden mit einem Hostingplan anlegen kann. Dazu ist mir aufgefallen, dass der Hosting Plan mit Namen benannt sein muss. Währe hier nicht die ID "robuster"?

Habs notiert kommt noch .

Ebenso kann man dem Kunden dann eine Domain zuordnen. Im Hostingbusiness ist es aber gang und gäbe, dass der Kunde nicht nur ein Hostingpaket sondern auch gleich die Domain ordert.
Daher meine Frage nach einer Vereinfachung des Vorgangs. Wäre es möglich bei der Bestellung gleich den Domainnamen zu "übergeben", so dass die Bestellung in einem Rutsch ausgeführt wird?

Aufgrund logischer Trennung würde das eher mit zwei Requests an die API lösen wollen. Das heißt im ersten Request legt man einen Benutzer an (erhält dann als Antwort die ID des Client zurück) und im zweiten Request legt man eine Domain an und gibt beim Request 'id_owner' = ID des eben angelegten Clienten an.

Ebenso wäre eine Prüfung auf "Domainnamen bereits vergeben" mit gleichzeitiger Auth-Code Übermittlung auch _sehr_ wichtig.

Das wäre mit einem Request an GET/domains/domain/meine-tolle-domain.de möglich. Wenn 404 als Response-Code dann gibts sie nicht.

-> Falls ich dich falsch verstanden hab, korrigiere mich gern nochmal

Da nach Rechtschreibfehlern gefragt wurde: Die API selbst ist, wenn ich nichts übersehen habe, fehlerfrei. In die Beschreibungen haben sich ein paar kleine Fehler eingeschlichen (einer mehrfach, nämlich "hosting-plan" - hier steht im Englischen kein Bindestrich):

-> Korrigiert, Danke!

[*]Bei GET /domains, GET /emails etc. werden jeweils ein UTF-8-Name und ein Punycode-Name zurückgegeben. Es sollte bei den POST-Methoden zumindest angegeben werden, welcher Wert angegeben werden muss. Dies selbst angeben zu können, wäre natürlich auch eine Option.

-> Es wird bei POST für die Variable "domain" utf8 sowie punycode akzeptiert. Habe das in als Beschreibung nun ergänzt.

[*]Bei POST ​/emails vermisse ich zumindest die Angabe der Größe, der Weiterleitungs-Adressen und ob es sich um einen reinen Forwarder handelt.

-> Die Werte standen in den Beispieldaten nicht dabei. Das ist nun ergänzt. Das Feld: "store_forwarded_emails" gibt Aufschluss darüber, ob es ein reiner Forwarder ist oder nicht.

[*]PUT ​/emails​/{id}: Werden hier zukünftig weitere Änderungsmöglichkeiten hinzugefügt? Funktioniert das Hinzufügen von Aliassen unmittelbar nach dem Anlegen einer E-Mail-Adresse oder erst, wenn der Cronjob gelaufen ist? Falls Letzteres, sollte auch das direkt beim Anlegen möglich sein.

-> Wie beim Punkt weiter oben, die Beispieldaten waren nicht vollständig, funktioniert also alles gleich schon beim Anlegen.

1. PHP-Versionen bei den Domains setzen kann.

-> Werde ich noch ergänzen.

2. Hostingpläne erstellen / Client-Konfigurationen einzeln updaten kann.

Du meinst, Hosting-Plane konfigurieren (also dann statt 1 GB Speicherplatz auf 2 GB Speicherplatz erweitern) bzw. analog das auch bei Client-Konfiguration? Das würde ich dann auch einen kommenden Release verschieben.


Vielen Dank nochmal!

----

Jetzt hat ja Christian in der Zwischenzeit geschrieben, da gehe ich später noch drauf ein - bist nicht vergessen .
Ach und MLAN hab ich bei meiner Antwort auch übersehen. Kommt im nächsten Post.