HTTP API als PHP-Klasse

So ich habe mir mal die Mühe gemacht und eine PHP-Klasse erstellt um noch einfacheren Zugriff auf die API zu bekommen:

http://www.qdaniel.de/sms77.class.phps

Um Feedback und Anregungen wird gebeten

Gruss euer QDaniel

Dein Server schickt mir die Datei als Download und zeigt sie nicht wie .phps vermuten lässt als Sourcecode.

Auf den ersten Blick fehlt mir die zugrunde liegende Lizenz. Also z.B. GPL oder einfach Freeware. So fehlt im Grunde jegliche Rechtssicherheit wenn die Klasse z.B. mit einem Projekt weitergegeben wird.

Mit CURL habe ich bisher noch nie gearbeitet. Ich weiß aber, dass diese keine Standarderweiterung von PHP ist und daher auch nicht bei jedem Anbieter verfügbar ist. Wo liegt der Vorteil CURL zu nutzen? Ich persönlich würde ganz nativ auf Sockets zurückgreifen.

Außerdem fehlt mir auf den ersten Blick die Verarbeitung des Statuscodes. Das kann ich aber auch übersehen haben.

Du hast in deiner Methode send_sms anscheinend einen logischen Bug. Du übergibts im Methodenheader z.b. $getstatus=false und prüfst später auf empty. Rein logisch betrachtet kann diese Variable nie leer sein.

Bei der Prüfung der Absenderlänge gibst du eine Warnung aus. Das sollte der Nutzer einstellen können. Ich persönlich würde die Klasse hier einen Fatal werfen lassen. Das ist aber sicherlich nur meine persönliche Ansichtssache.

Die Parameter Benutzername sowie Passwort können auch per POST übergeben werden während der Rest als GET übergeben werden muss. Da so verhindert wird, dass die heiklen Benutzerdaten in irgendwelchen Logs landen währe eine Unterstützung dafür wünschenswert. Ebenso wäre es schön wenn das Passwort per default in einen MD5-Hash umgewandelt werden würde.

Als weiter Komfortfunktion sollte einstellbar sein ob lange SMS verschickt werden sollen. Je nach Anwendung möchte man unter allen Umständen verhindern, dass mehr als die 160 Zeichen verschickt werden.

Alles in allem ist eine PHP-Klasse sicher angenehmer zu nutzen als den ganzen Code zur Verarbeitung selbst zu schreiben. Aber im Moment bietet deine Klasse kaum einen Mehrwert da der meiste Code mit Fallunterscheidungen beschäftigt ist. Was spricht eigentlich gegen eine PHP5 Klasse? PHP4 wird nicht mehr besonders lange weiterentwickelt. Lass dich von mir aber jetzt nicht entmutigen. Du hast ja mit der Arbeit gerade erst angefangen.

Nachtrag: Ich weiß, dass eine mit false belegte Variable von empty() als leer erkannt wird. Trotzdem würde ich hier eindeutiger prüfen. Ich kann deiner Methode einige verschiedene Werte übergeben die mir empty() als leer quittieren. Dies ändert zwar nichts an Ablauf des Codes wirkt aber dreckig. Sinnvoll währe es auf einen boolschen Typ zu prüfen und gegebenenfalls einen Fehler zu werfen wenn keiner übergeben wurde.

Zuletzt bearbeitet: 13.08.2007 15:24 - Insgesamt 1 mal bearbeitet.

Das mit der Anzeige von phps Ist leider bei meinem Hoster nicht eingerichtet. evtl. Frag ich da mal an.

So die Lizenz habe ich hinzugefügt.

So wie alle Trigger auf ERROR gesetzt.

Nein cUrl ist keine Standard Erweiterung aber auf vielen Server aktiv.
Evtl. füge ich noch eine fopen Verbindung hinzu.

Ja die Statuscodes sind noch nicht eingebaut diese werden aber folgen.

Ja das mit empty ist ne Angewohnheit von mir.

Unter Verwendung von cUrl werden nun die Logindaten per POST gesendet.

Eine PHP5 Klasse werde ich demnächst mal überdenken , nur ist das Problem das PHP4 keine PHP5 Klassen lesen kann und leider viele Server noch mit PHP4 arbeiten.

Ging aber schnell. Ich werde mir die Klasse morgen noch einmal genauer anschauen. Was mir gerade im Moment noch aufgefallen ist, ist dass manche Methoden nur fallweise einen Wert zurück geben. In den (meisten) Fällen ein false. Hier sollte aber in jedem Fall etwas zurück kommen. Und wenn es nur ein true ist.

Gn8 Frank

Zuletzt bearbeitet: 13.08.2007 21:15 - Insgesamt 1 mal bearbeitet.

also eigentlich wird immer ein Wert zurück gegeben,
entweder false wenn irgend ein logischer Fehler aufgetreten ist
oder der Rückgabe wert der API.

Einige Dinge sind mir gerade bei genauerer Prüfung aufgefallen:
1. Prüfung des Nachrichten-Types redundant.
2. Prüfung sollte case insensitive sein.
3. Methodenrückgabe False überflüssig wenn ERROR getriggert wird.
4. Absenderkennung zu lang -> ERROR -> gekürzt? Fehlermeldung jetzt verwirrend.

Du benutzt häufig Code in dieser Form:
if(!$this->_checkparams($to,'to')) return false;
Da _checkparams die Codeausführung sowieso abbricht ist weder das if noch das return nötig. Der einfache Aufruf reicht in diesem Fall.

Du hast eine Methode set_from und übernimmst diesen Parameter aber auch in den send_* Methoden -> redundant

get_balance() gibt bei falschem User/PW nichts zurück.

get_adressbook() liefert in diesem Fall ein Array mit einem Wert 900.


Meine persönlichen Änderungsvorstellungen:
Die einzelnen send_* Methoden sollten zusammen gefasst werden als send(). Dazu währe es nötig die verschiedenen Parameter einzeln zu sammeln und erst beim Senden zu prüfen ob alles vorhanden ist. Das ist aufgrund des Nachrichten Typs ja problemlos möglich.

Außerdem sollte die Klasse "vorkonfigurierbar" sein. Daher sollte es möglich sein per extend eine Klasse abzuleiten die Werte wie z.B. from bereits setzt. Dazu müsste es aber nötig sein auf diverse Parameter beim Aufruf verzichten zu können.

z.B.:
class mysms77 extends sms77 {
var $params = array('curl' => false, 'ssl' => false);
}

Oder schöner vielleicht:
class mysms77 extends sms77 {
var $curl = false;
var $ssl = false;
}

Gruß Frank

Edit: Du musst nicht alles so machen wie ich mir das vorstelle. Ich sehe hier aber eine Chance für mehr Komfort bei der Nutzung der Klasse. Und auch ich habe Denkfehler. Die darfst du mir auch auf die Nase binden.

Edit 2: Mir ist gerade erst aufgefallen, dass dein ERROR nur eine Warnung ist. Daher machen die return(false) dann auch Sinn. Jedenfalls mit einem eigenen error_handler.

Zuletzt bearbeitet: 14.08.2007 11:08 - Insgesamt 3 mal bearbeitet.