HTTP POST request Class
Door Daan , 20 jaar geleden, 6.383x bekeken
Ik was op zoek naar een class om een POST request te versturen, die makkelijk aan te passen is. Maar ik kon er nergens een vinden, dus moest zelf aan de slag ;)
Nu ben ik wel zo aardig om deze nu dan ook met jullie te delen, zodat jullie ook mee kunnen genieten van mijn script-kunsten... :D
Ik heb hem zo gemaakt, dat hij makkelijk is aan te passen en uit te breiden. Daarom wordt er soms ook een beetje omslachtig gewerkt, zoals eerst een array maken, en daarna van die array een string. Een array is later (als je zelf iets wilt veranderen) makkelijker aan te passen.
Alle commentaar is natuurlijk welkom, ik wil de classe zelf ook zo perfect mogelijk hebben ;)
Veel plezier ermee!
De versie 2 van deze classe is hier te vinden:
http://www.phphulp.nl/php/scripts/4/1415
Gesponsorde koppelingen
PHP script bestanden
Er zijn 12 reacties op 'Http post request class'
0 
-0 
-0
Ziet er heel aardig uit!
Ik heb echter nog wel een aantal opmerkingen:
- Je gebruikt bij je PHP vaak engels en nederlands door elkaar. Probeer één taal aan te houden. Je hebt bijvoorbeeld de methode verzendRequest(). Dit zou of sendRequest(), of verzendVraag() ofzo moeten zijn.
- Alhoewel dit geen standaard is, en voor iedereen eigen keuze is wil ik aanraden om je comment om te zetten in phpdoc, en dan het liefst in het engels. Zo wordt je klasse zo universeel mogelijk.
-Als je ergens een verbinding maakt met fsockopen(), dan geef je het vaste timeout argument 30 mee. Misschien is het een idee om die variabel te maken, en om hem door de gebruiker van de klasse mee te laten sturen in een argument.
- Ik mis getters en setters waarmee je na de constructie van de klasse de host, poort, headers en argumenten nog kunt instellen. Dat kan soms handig zijn.
- Je hebt een rare manier van error-handling. Je gooit voor zover ik kan zien alleen in de methode verzenRequest() een aantal Excepties, maar die vang je meteen op, en je stuurt ze door naar errorHandler(). In alle andere functies roep je errorHandler() direct op, zonder Exceptie. Dit is sowieso al raar, maar wat nog raarder is, is dat errorHandler() vrolijk een die() met html opmaak aanroept. Dit houdt dus in dat het hele script gestopt wordt, zonder dat het script dat de klasse heeft aangevraagd dat weet, en dat op het scherm van de gebruiker een error staat, waarover het script dat de klasse aanroept geen enkele zeggenschap heeft, en ook totaal niet in de stijl van de website is. Dat komt niet echt ten goede van de herbruikbaarheid van de klasse. Als je al werkt met een errorHandler() zou ik je aanraden om in de methode die de error veroorzaakt een return false te laten geven, en hem dan een variabele laten zetten met een string met informatie over de error. Vervolgens kan de gebruiker van de klasse via errorHandler die error verkrijgen. Denk er dan wel aan dat je de error zonder html opmaakt, en hem returnt en niet die()'t.
Nog beter zou echter zijn (naar mijn mening) als je in elke methode gewoon Excepties maakt, en deze teruggooit naar de gebruiker van de klasse. Deze heeft dan de verantwoordelijkheid dit op te vangen, en hij heeft veel gedetailleerdere informatie over de error, zoals een stacktrace. Ook hoef je nu in je methoden niet meer van die ingewikkelde if-stucturen te gebruiken, maar kun je gewoon zodra het fout gaat een Exceptie gooien, en dan wordt het hele script op dat niveau getermineert.
Ook kun je om je Excepties nog meer te specificeren kijken naar de spl Excepties van php.
Ik hoop dat je hier wat aan hebt, en dat al mijn informatie correct is:P
Lasse
Ik heb echter nog wel een aantal opmerkingen:
- Je gebruikt bij je PHP vaak engels en nederlands door elkaar. Probeer één taal aan te houden. Je hebt bijvoorbeeld de methode verzendRequest(). Dit zou of sendRequest(), of verzendVraag() ofzo moeten zijn.
- Alhoewel dit geen standaard is, en voor iedereen eigen keuze is wil ik aanraden om je comment om te zetten in phpdoc, en dan het liefst in het engels. Zo wordt je klasse zo universeel mogelijk.
-Als je ergens een verbinding maakt met fsockopen(), dan geef je het vaste timeout argument 30 mee. Misschien is het een idee om die variabel te maken, en om hem door de gebruiker van de klasse mee te laten sturen in een argument.
- Ik mis getters en setters waarmee je na de constructie van de klasse de host, poort, headers en argumenten nog kunt instellen. Dat kan soms handig zijn.
- Je hebt een rare manier van error-handling. Je gooit voor zover ik kan zien alleen in de methode verzenRequest() een aantal Excepties, maar die vang je meteen op, en je stuurt ze door naar errorHandler(). In alle andere functies roep je errorHandler() direct op, zonder Exceptie. Dit is sowieso al raar, maar wat nog raarder is, is dat errorHandler() vrolijk een die() met html opmaak aanroept. Dit houdt dus in dat het hele script gestopt wordt, zonder dat het script dat de klasse heeft aangevraagd dat weet, en dat op het scherm van de gebruiker een error staat, waarover het script dat de klasse aanroept geen enkele zeggenschap heeft, en ook totaal niet in de stijl van de website is. Dat komt niet echt ten goede van de herbruikbaarheid van de klasse. Als je al werkt met een errorHandler() zou ik je aanraden om in de methode die de error veroorzaakt een return false te laten geven, en hem dan een variabele laten zetten met een string met informatie over de error. Vervolgens kan de gebruiker van de klasse via errorHandler die error verkrijgen. Denk er dan wel aan dat je de error zonder html opmaakt, en hem returnt en niet die()'t.
Nog beter zou echter zijn (naar mijn mening) als je in elke methode gewoon Excepties maakt, en deze teruggooit naar de gebruiker van de klasse. Deze heeft dan de verantwoordelijkheid dit op te vangen, en hij heeft veel gedetailleerdere informatie over de error, zoals een stacktrace. Ook hoef je nu in je methoden niet meer van die ingewikkelde if-stucturen te gebruiken, maar kun je gewoon zodra het fout gaat een Exceptie gooien, en dan wordt het hele script op dat niveau getermineert.
Ook kun je om je Excepties nog meer te specificeren kijken naar de spl Excepties van php.
Ik hoop dat je hier wat aan hebt, en dat al mijn informatie correct is:P
Lasse
Edit:
Typo
0 -0
-0
Ik zou niet al die vars private maken met de volgende reden. Je class is een HTTP request. Het zou kunnen dat je in de toekomst de class wil extenden, bijvoorbeeld "getRequest extends httpRequest" of "postRequest extends httpRequest". Dan kun je dus je variabelen niet meer aanspreken, beetje onpraktisch. Verder even commentaar van Lasse bekijken :)
0 -0
-0
Quote:
Ik was op zoek naar een class om een POST request te versturen
In de vorm van form submit ?
edit,
echter vind ik het wel een geinig script, maar de variable namen, en functie name zouden in het engels beter zijn. Ook geven ze niet goed aan wat het is..
0 -0
-0
Zelf gebruik ik altijd cURL voor dit soort dingen. De meeste hosters hebben dit wel geïnstalleerd.
0 -0
-0
@admir: Daar zijn wij ook blij mee. Hij vraagt in zijn post zelf om kritiek. En alle kritiek die hier gepost wordt is zeer opbouwen on onderbouwd. Het is allemaal gewoon bedoelt om het script te verbeteren...
0 -0
-0
@Iedereen: bedankt voor de kritiek!
@Admir: Fijn dat je het voor me opneemt, maar deze kritiek kan ik idd wel wat mee.
@Lasse: You're right ;)
Oke, dit is voor mij het eerste script dat ik hier post, dus ook het eerste script waar ik kritiek op krijg. Zijn wel puntjes die eigenlijk wel op al mijn scripts van toepassing zijn, dus wordt het voor mij misschien eens tijd om mijn manier van scripten te veranderen.
- Over dat Engels en Nederlands door elkaar: daar heb ik vaak last van ;) Ik heb deze keer geprobeerd alles nederlands te houden, alleen 'Request' en 'Response' wist ik eigenlijk geen goede nederlandse vertaling, en ik ging er vanuit dat het zo ook wel duidelijk was. Als ik nu terug kijk, zie ik dat ik ook 'header', 'body', 'errorHandler' en 'FilePointer' heb gebruikt.
- Phpdoc heb ik eigenlijk nog nooit mee gewerkt, maar ga het eens uitzoeken. Zal niet heel ingewikkeld zijn, dus wel handig als ik dat ook onder de knie krijg. In het engels? Dan het hele script maar. Ik zal alles wel veranderen in het engels: universeel en alles hetzelfde.
- getters en setters zijn niet heel erg moeilijk (zelfs heel makkelijk) erbij te maken. Het is een classe die zo gemaakt is, dat hij makkelijk is aan te passen. Als je het nodig hebt, ik hou je niet tegen ze te maken. Ik heb ze niet nodig, maar zal ze er ook maar ff bijmaken.
- Die error afhandeling is nooit echt mijn sterkste kant geweest. Dat dat die() niet goed is, weet ik! Die functie zit er eigenlijk zó in, dat je die moet aanpassen aan je eigen website, zodat hij overal makkelijk te integreren is.
Ik ga overal die excepties toevoegen, alleen ik snap niet echt hoe je bedoelt dat je die naar de gebruiker teruggooit. Bedoel je via een return?? Wat moet er volgens jou (Lasse) in de catch?
Protected is inderdaad een betere oplossing! Ga ik doen! Op internet staan vaak alle voorbeelden óf zonder zo'n voorvoegsel (hoe heet dat?), óf als public/private. Protected kom je eigenlijk nergens tegen. Wel raar, want is idd wel beter, denk ik.
@iltar van der berg:
nee, niet als form submit, maar zoals ik in dit script heb gedaan ;)
Waarom denk jij trouwens dat het in het engels beter is? Ik ga het idd in het engels omzetten, maar ben benieuwd waarom jij het vind? Omdat dat jouw gewoonte is, of heb je d'r een echte reden voor ;)
@Steffan:
Ik wilde eerst ook cURL gebruiken, maar heb ff op internet gegoogled naar wat beter is. Wat ik vond, vertelde me dat fsockopen vaker aanstaat op servers, dat het sneller is, dat het makkelijker is, maar dat je minder mogelijkheden hebt. De mogelijkheden heb ik niet nodig, dus heb ik gekozen voor fsockopen.
Weet iemand trouwens of het ook wel voorkomt dat fsockopen geblokkeerd is, en dat cURL het wel doet? Want dan kan ik misschien iets maken dat als fsockopen het niet doet, hij het met cURL probeert.
@Admir: Fijn dat je het voor me opneemt, maar deze kritiek kan ik idd wel wat mee.
@Lasse: You're right ;)
Oke, dit is voor mij het eerste script dat ik hier post, dus ook het eerste script waar ik kritiek op krijg. Zijn wel puntjes die eigenlijk wel op al mijn scripts van toepassing zijn, dus wordt het voor mij misschien eens tijd om mijn manier van scripten te veranderen.
- Over dat Engels en Nederlands door elkaar: daar heb ik vaak last van ;) Ik heb deze keer geprobeerd alles nederlands te houden, alleen 'Request' en 'Response' wist ik eigenlijk geen goede nederlandse vertaling, en ik ging er vanuit dat het zo ook wel duidelijk was. Als ik nu terug kijk, zie ik dat ik ook 'header', 'body', 'errorHandler' en 'FilePointer' heb gebruikt.
- Phpdoc heb ik eigenlijk nog nooit mee gewerkt, maar ga het eens uitzoeken. Zal niet heel ingewikkeld zijn, dus wel handig als ik dat ook onder de knie krijg. In het engels? Dan het hele script maar. Ik zal alles wel veranderen in het engels: universeel en alles hetzelfde.
- getters en setters zijn niet heel erg moeilijk (zelfs heel makkelijk) erbij te maken. Het is een classe die zo gemaakt is, dat hij makkelijk is aan te passen. Als je het nodig hebt, ik hou je niet tegen ze te maken. Ik heb ze niet nodig, maar zal ze er ook maar ff bijmaken.
- Die error afhandeling is nooit echt mijn sterkste kant geweest. Dat dat die() niet goed is, weet ik! Die functie zit er eigenlijk zó in, dat je die moet aanpassen aan je eigen website, zodat hij overal makkelijk te integreren is.
Ik ga overal die excepties toevoegen, alleen ik snap niet echt hoe je bedoelt dat je die naar de gebruiker teruggooit. Bedoel je via een return?? Wat moet er volgens jou (Lasse) in de catch?
Protected is inderdaad een betere oplossing! Ga ik doen! Op internet staan vaak alle voorbeelden óf zonder zo'n voorvoegsel (hoe heet dat?), óf als public/private. Protected kom je eigenlijk nergens tegen. Wel raar, want is idd wel beter, denk ik.
@iltar van der berg:
nee, niet als form submit, maar zoals ik in dit script heb gedaan ;)
Waarom denk jij trouwens dat het in het engels beter is? Ik ga het idd in het engels omzetten, maar ben benieuwd waarom jij het vind? Omdat dat jouw gewoonte is, of heb je d'r een echte reden voor ;)
@Steffan:
Ik wilde eerst ook cURL gebruiken, maar heb ff op internet gegoogled naar wat beter is. Wat ik vond, vertelde me dat fsockopen vaker aanstaat op servers, dat het sneller is, dat het makkelijker is, maar dat je minder mogelijkheden hebt. De mogelijkheden heb ik niet nodig, dus heb ik gekozen voor fsockopen.
Weet iemand trouwens of het ook wel voorkomt dat fsockopen geblokkeerd is, en dat cURL het wel doet? Want dan kan ik misschien iets maken dat als fsockopen het niet doet, hij het met cURL probeert.
0 -0
-0
@Daan: Ik geef even een abstract Exception voorbeeld, met twee splExceptions er in. Zoals je ziet zit er in de klasse helemaal geen try-catch.
En ik zit daarnet wel zo op te scheppen over de engelse taal, maar dat is zelf ook niet mijn sterkste punt, dus vergeef mij voor het slechte commentaar.
Overgins zit er ook geen phpdoc in, want dat zou wat veel ruimte in beslag nemen...
En ik zit daarnet wel zo op te scheppen over de engelse taal, maar dat is zelf ook niet mijn sterkste punt, dus vergeef mij voor het slechte commentaar.
Overgins zit er ook geen phpdoc in, want dat zou wat veel ruimte in beslag nemen...
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
<?php
class Foo {
protected $bar;
public function __construct($bar) {
if (!is_string($bar)) {// $bar needs to be an string, when not,
//trhow an InvalidArgumentException. See SPL exceptions
throw new InvalidArgumentException('Argument $bar needs to be an string.');
}
$this->bar = $bar;
if (!is_array($this->returnArray())) {// check if returnArray is returning an array, when not,
//throw an UnexpectedValueException. See SPL exceptions
throw new UnexpectedValueException('Method returnArray did not return an array.');
}
}
protected function returnArray() {// Function supposed to return an array
return 15;// But it is returning an integer
}
}
try {
$foo = new Foo(array('foo', 'bar'));
} catch (Exception $e) {
echo $e->getMessage();// This wil echo 'Argument $bar needs to be an string.'
}
try {
$foo = new Foo('foobar');
} catch (Exception $e) {
echo $e->getMessage();//This wil echo 'Method returnArray did not return an array.'
}
?>
class Foo {
protected $bar;
public function __construct($bar) {
if (!is_string($bar)) {// $bar needs to be an string, when not,
//trhow an InvalidArgumentException. See SPL exceptions
throw new InvalidArgumentException('Argument $bar needs to be an string.');
}
$this->bar = $bar;
if (!is_array($this->returnArray())) {// check if returnArray is returning an array, when not,
//throw an UnexpectedValueException. See SPL exceptions
throw new UnexpectedValueException('Method returnArray did not return an array.');
}
}
protected function returnArray() {// Function supposed to return an array
return 15;// But it is returning an integer
}
}
try {
$foo = new Foo(array('foo', 'bar'));
} catch (Exception $e) {
echo $e->getMessage();// This wil echo 'Argument $bar needs to be an string.'
}
try {
$foo = new Foo('foobar');
} catch (Exception $e) {
echo $e->getMessage();//This wil echo 'Method returnArray did not return an array.'
}
?>
0 -0
-0
Quote:
nee, niet als form submit, maar zoals ik in dit script heb gedaan ;)
Waarom denk jij trouwens dat het in het engels beter is? Ik ga het idd in het engels omzetten, maar ben benieuwd waarom jij het vind? Omdat dat jouw gewoonte is, of heb je d'r een echte reden voor ;)
Waarom denk jij trouwens dat het in het engels beter is? Ik ga het idd in het engels omzetten, maar ben benieuwd waarom jij het vind? Omdat dat jouw gewoonte is, of heb je d'r een echte reden voor ;)
PHP is engels, PHP functies zijn in het engels etc. Engels is gewoon een universele taal. Als ik op mijn werk met iemand ga praten die geen nederlands praat en bv alleen engels, praat ik ook alleen engels. Het word gewoon onoverzichtelijk als je het in het nederlands doet. Maar boven al begrijpt iedereen het ook goed.
$e->getMessage();
$e->pakBericht();
0 -0
-0
Weer veel opbouwend commentaar. Nice.
Ok nog eentje: Voor het 'verwerken' van de URL kan je misschien deze functie gebruiken: parse_url() -> http://php.net/parse_url
Zoals ik zei: misschien. Volgens mij is namelijk een voorwaarde dat het een complete URL is, dus incl http://. Als je dat niet wil, moet je zelf iets bedenken, maar denk aub aan de volgende URL: www.website.com:8080/config/. Wat gebeurt daar mee?
Just an idea.
Ok nog eentje: Voor het 'verwerken' van de URL kan je misschien deze functie gebruiken: parse_url() -> http://php.net/parse_url
Zoals ik zei: misschien. Volgens mij is namelijk een voorwaarde dat het een complete URL is, dus incl http://. Als je dat niet wil, moet je zelf iets bedenken, maar denk aub aan de volgende URL: www.website.com:8080/config/. Wat gebeurt daar mee?
Edit:
En misschien, maar dat is puur educatief, kan je eens kijken naar een object als return value van de exectute method van de httpRequest class. Dus een onderscheid maken tussen Request en Response, bijv door klassen HttpRequest en HttpResponse te maken. Als je HttpRequest->execute() (oid) uitvoert, krijg je een object van type HttpResponse terug. Ofwel:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
<?php
$request = new HttpRequest('www.website.nl/dir/map/ok.php');
$request->setBody('a=b&c[]=d&c[]=e');
$response = $request->execute(true); // enige argument is of "Location" headers gevolgd moeten worden bv
$szHeaders = $response->getHeaders();
$szBody = $response->getBody();
$szContentType = $response->getHeader('Content-Type'); // hier zijn heel veel methoden voor
?>
$request = new HttpRequest('www.website.nl/dir/map/ok.php');
$request->setBody('a=b&c[]=d&c[]=e');
$response = $request->execute(true); // enige argument is of "Location" headers gevolgd moeten worden bv
$szHeaders = $response->getHeaders();
$szBody = $response->getBody();
$szContentType = $response->getHeader('Content-Type'); // hier zijn heel veel methoden voor
?>
Just an idea.
0 -0
-0
Hey,
Ik heb nu een tweede versie gemaakt van dit script. Er is lekker veel veranderd, dus lijkt niet eens meer op dit script..
Maar moet ik nu dit script edit-en, dan is dit script weg. Of moet een een nieuw script uploaden en dat 'HTTP POST request Class V2' noemen? Of nog iets anders?
Daan
Ik heb nu een tweede versie gemaakt van dit script. Er is lekker veel veranderd, dus lijkt niet eens meer op dit script..
Maar moet ik nu dit script edit-en, dan is dit script weg. Of moet een een nieuw script uploaden en dat 'HTTP POST request Class V2' noemen? Of nog iets anders?
Daan
Edit:
Nou, ik heb hem apart toegevoegd, hoor. Anders snap je niet meer waar deze reacties over gaan, als iemand dat ooit nog eens een keer wilt lezen.
Om te reageren heb je een account nodig en je moet ingelogd zijn.
PHP hulp
0 seconden vanaf nu