REST API - Einfache Abfragen über http

joekater schrieb:
Was sagst du zu meiner Config?
Das dein server PHP kann.

Bevor du das CURL Ding debuggst.

Würde ich einfach mal versuchen herauszufinden warum dein "echo" nicht funktioniert hat.

Leere test.php erstellen, dann dort echo "irgendwas"

wenn das klappt dort die Rest Abfrage machen.
 
  • Gefällt mir
Reaktionen: joekater
Danke für die Rückmeldung - Mittlerweile klappt es mit dem Aufruf der Seiten, es lag tatsächlich um den Speicherort.
Jetzt bin ich gerade dabei, die Daten über die API anzeigen zu lasen und siehe da: "Call to undefined function curl_init()" :grr:
 
PHP hat ganz viele Erweiterungen eine davon curl (ist auch eine ziemlich gängige). Deine PHPInfo Screenshot habe ich entnommen, dass du auf einem Windows Server arbeitest daher kann ich dir da nicht mal mehr gross helfen.

Ich hab Widnows das lette mal vor über 20 Jahren so wirklich verwendet und in meinem Leben noch nie PHP unter Windows eingerichtet.

Auf einem Linux System wäre das Problem mit einem:

Bash:
sudo apt install php-curl

## oder

sudo dnf install php-curl

erledigt.

Das muss du selber googeln, oder villeicht kennt sich hier sonst jemand mit PHP für Windows aus.
 
Naja die phpinfo(); enthält eigentlich auch die Listung aller Module und deren Config. Wenn der @TE einfach mal alle gefragten Informationen (vollständig) angeben würde, anstatt immer nur Fragmente, würde das den Helfenden sehr helfen.

Und was auch hilft, sind code-Blöcke im Forum zu verwenden um Informationen gut Formatiert darzustellen. Mit dem Vorteil, dass man Informationen über die Suche auch besser findet, als sie in Screenshots suchen zu müssen. Gerade die phpinfo() bekommt man im Terminal/der Konsole ja ebenfalls über php -i.

Code:
phpinfo()
PHP Version => 8.1.2-1ubuntu2.10

System => Linux ufo 5.15.0-57-generic #63-Ubuntu SMP Thu Nov 24 13:43:17 UTC 2022 x86_64
Build Date => Jan 16 2023 15:19:49
Build System => Linux
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /etc/php/8.1/cli
Loaded Configuration File => /etc/php/8.1/cli/php.ini
Scan this dir for additional .ini files => /etc/php/8.1/cli/conf.d
Additional .ini files parsed => /etc/php/8.1/cli/conf.d/10-opcache.ini,
/etc/php/8.1/cli/conf.d/10-pdo.ini,
/etc/php/8.1/cli/conf.d/15-xml.ini,
/etc/php/8.1/cli/conf.d/20-apcu.ini,
/etc/php/8.1/cli/conf.d/20-bcmath.ini,
/etc/php/8.1/cli/conf.d/20-bz2.ini,
/etc/php/8.1/cli/conf.d/20-calendar.ini,
/etc/php/8.1/cli/conf.d/20-ctype.ini,
/etc/php/8.1/cli/conf.d/20-curl.ini,
/etc/php/8.1/cli/conf.d/20-dom.ini,
/etc/php/8.1/cli/conf.d/20-exif.ini,
/etc/php/8.1/cli/conf.d/20-ffi.ini,
/etc/php/8.1/cli/conf.d/20-fileinfo.ini,
/etc/php/8.1/cli/conf.d/20-ftp.ini,
/etc/php/8.1/cli/conf.d/20-gd.ini,
/etc/php/8.1/cli/conf.d/20-gettext.ini,
/etc/php/8.1/cli/conf.d/20-gmp.ini,
/etc/php/8.1/cli/conf.d/20-iconv.ini,
/etc/php/8.1/cli/conf.d/20-igbinary.ini,
/etc/php/8.1/cli/conf.d/20-imagick.ini,
/etc/php/8.1/cli/conf.d/20-intl.ini,
/etc/php/8.1/cli/conf.d/20-mbstring.ini,
/etc/php/8.1/cli/conf.d/20-memcache.ini,
/etc/php/8.1/cli/conf.d/20-msgpack.ini,
/etc/php/8.1/cli/conf.d/20-pdo_pgsql.ini,
/etc/php/8.1/cli/conf.d/20-pgsql.ini,
/etc/php/8.1/cli/conf.d/20-phar.ini,
/etc/php/8.1/cli/conf.d/20-posix.ini,
/etc/php/8.1/cli/conf.d/20-readline.ini,
/etc/php/8.1/cli/conf.d/20-shmop.ini,
/etc/php/8.1/cli/conf.d/20-simplexml.ini,
/etc/php/8.1/cli/conf.d/20-sockets.ini,
/etc/php/8.1/cli/conf.d/20-sysvmsg.ini,
/etc/php/8.1/cli/conf.d/20-sysvsem.ini,
/etc/php/8.1/cli/conf.d/20-sysvshm.ini,
/etc/php/8.1/cli/conf.d/20-tokenizer.ini,
/etc/php/8.1/cli/conf.d/20-xmlreader.ini,
/etc/php/8.1/cli/conf.d/20-xmlwriter.ini,
/etc/php/8.1/cli/conf.d/20-xsl.ini,
/etc/php/8.1/cli/conf.d/20-zip.ini
[...]

curl

cURL support => enabled
cURL Information => 7.81.0
Age => 9
Features
AsynchDNS => Yes
CharConv => No
Debug => No
GSS-Negotiate => No
IDN => Yes
IPv6 => Yes
krb4 => No
Largefile => Yes
libz => Yes
NTLM => Yes
NTLMWB => Yes
SPNEGO => Yes
SSL => Yes
SSPI => No
TLS-SRP => Yes
HTTP2 => Yes
GSSAPI => Yes
KERBEROS5 => Yes
UNIX_SOCKETS => Yes
PSL => Yes
HTTPS_PROXY => Yes
MULTI_SSL => No
BROTLI => Yes
Protocols => dict, file, ftp, ftps, gopher, gophers, http, https, imap, imaps, ldap, ldaps, mqtt, pop3, pop3s, rtmp, rtsp, scp, sftp, smb, $
Host => x86_64-pc-linux-gnu
SSL Version => OpenSSL/3.0.2
ZLib Version => 1.2.11
libSSH Version => libssh/0.9.6/openssl/zlib

Directive => Local Value => Master Value
curl.cainfo => no value => no value

Zum allgemeinen Programmierstil vom @TE, es wird einfach keine Fehlerbehandlung vorgesehen.
$result = curl_exec($curl); wobei $result sofort in einer Schleife verwendet wird, ohne zu prüfen, ob curl überhaupt erfolgreich eine Verbindung herstellen konnte. Das ist mehrfach eine schlechte Idee.
1. So wie jetzt kann nicht nachvollzogen werden, ob der Fehler bei der Verbindung via curl ist, oder an anderer Stelle der Logik
2. Sollte curl auf stdout Fehler auswerfen (weil es der abgefragte Server so ausspuckt) leakt dein Code tendenziell die Fehler.

Es wäre zu empfehlen dem Code eine Fehlerbehandlung zu verpassen, bzw. konkreter Logik, die eine weitere Ausführung nur erlaubt, wenn curl mit einem http-code der 200er Familie abgeschlossen hat.
Und um das Leben als Entwickler zu vereinfachen sollte sich @TE mal mit den Debugoptionen von PHP beschäftigen. In Entwicklungsumgebungen kann man Webserver und PHP oftmals Optionen verpassen, sodass sie Stderr[1] ausgeben. Was man entsprechend in Produktivumgebungen ausschalten sollte.

Letzter Hinweis, php läuft auch auf dem Terminal/Console. Da kann man auch mal kleinere codeschnipsel hacken und testen.


[1] bzw entsprechendes unter Windows
 
  • Gefällt mir
Reaktionen: joekater, sh., Cool Master und eine weitere Person
Welche Entwickler geben dir den Code vor? Und was bist du? Bzw. welche Rolle spielst du?
Oder kommt die Aufgabe vom Lehrer?
 
  • Gefällt mir
Reaktionen: Piktogramm
kim88 schrieb:
Das dein server PHP kann.

Bevor du das CURL Ding debuggst.

Würde ich einfach mal versuchen herauszufinden warum dein "echo" nicht funktioniert hat.

Leere test.php erstellen, dann dort echo "irgendwas"

wenn das klappt dort die Rest Abfrage machen.
Echo wird gezeigt, Ablageort war falsch - Ich dachte, ich kann tricksen, da ich keine Änderung an der Datei direkt in dem Webserver Ordner vornehmen kann.
 
@joekater
Du hast ein entscheidendes Problem:

Du willst schnell was fertig bekommen und gehst nicht daher den langen steinigen Weg des Lernens und Verstehens, sondern stellst konkrete Fragen im Forum und probierst mit den Antworten rum.

Obwohl es sich anstrengend und langwierig anhören mag, wäre mein Rat, damit aufzuhören und ein strukturiertes Tutorial durchzuarbeiten, um zu verstehen, was du da machst.

Sowas hier: https://php-tut.awesumdude.tv/index.html
Und schau dir die Doku an: https://php.net
 
  • Gefällt mir
Reaktionen: sh.
sh. schrieb:
Welche Entwickler geben dir den Code vor? Und was bist du? Bzw. welche Rolle spielst du?
Oder kommt die Aufgabe vom Lehrer?
Das ist tatsächlich ein Projekt von unserem Betreuer - Mache eine Ausbildung zum Mechatroniker.
 
Gerade für angehende Mechatroniker will ich nochmal darauf hinweisen, dass es wichtig ist Checks durchzuführen, ob externe Daten, externe Aufrufe von irgendwas valide sind. Prinzipiell auch so, dass der Default ein Fail ist, dessen Konsequenten perfekt(!) abgefangen werden und nur erfolgreich verifizierte Daten/Eingaben/Ausführungen zu einem Weiterlaufen der Logik führen!

In deinem Fall, also verifizieren, dass curl überhaupt erfolgreich Ressourcen der API abfragen konnte. Und eigentlich sollte man auch prüfen, ob das Format (hier: Ist es json? Hat json die erwarteten Datenfelder? Haben Datenfelder Werte in erwartetem Bereich?). Erst danach sollte eine weitere Verarbeitung stattfinden.

In der Praxis machen das Viele nicht, in der Ausbildung/im Studium wird das oft auch sträflich missachtet.
 
Was ist denn aktuell das Problem?
Du hast eine API auf deinem lokalen PC laufen (localhost:8080) und willst diese nun konsumieren über eine neue Seite. Okay... dafür gibt es 10000 Wege.

Willst du nur den API Output ausgeben?
Dann brauchst du nicht mal PHP sondern ein Tool wie Postman oder Insomnia o.Ä.

Falls es mit CURL nicht geht, weil dir die PHP Extension fehlt, dann versuch mal mit "file_get_contents".
https://stackoverflow.com/questions/959063/how-to-send-a-get-request-from-php

Lass alles im try-catch Block laufen, dann siehst die Fehler sofort.
PHP:
$result = [];

try {
    $curl = curl_init();
    curl_setopt($curl, CURLOPT_URL, "http://localhost:8080/api/v1/bases");
    curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($curl, CURLOPT_HTTPHEADER, [
        "Accept: application/json",
        "x-access-token: BCDHBFDBLCXHYA"
    ]);
    $result = curl_exec($curl);
} catch (\Throwable $throwable) {
    var_dump($throwable->getMessage());
    // UPS, hier ist was schief gelaufen -> siehe var_dump Ausgabe
}

var_dump($result);
// mach hier weiter mit schleife oder Ähnliches.
 
  • Gefällt mir
Reaktionen: joekater
Vielleicht habe ich was überlesen, aber warum überhaupt PHP und gleich am Anfang die Frage nach Backend? Warum nicht einfach mit javascript und fetch die API abfragen? Oder muss der Request irgendwie Serverseitig verarbeitet werden?
 
@[ChAoZ]
Wer Anfängern etwas von Exceptions, throwable und var_dump erzählt, sollte auch gleich dazu erzählen, welche Implikationen das im Bezug aus Security haben kann -.-!

@jb_alvarado
Der @joekater braucht für seinen API-Zugriff einen API-Key. Den mittels Javascript im FrontEnd, also dem Nutzer zugänglich zu machen ist meist unerwünscht. Also es gehört ins Backend und da ist Javascript nicht verfügbar, solang man explizit kein NodeJS oder Vergleichbares hat.
 
Piktogramm schrieb:
Wer Anfängern etwas von Exceptions, throwable und var_dump erzählt, sollte auch gleich dazu erzählen, welche Implikationen das im Bezug aus Security haben kann -.-!
Erzähl mal.... ich habe nämlich keine Ahnung was du damit meinst.
 
@[ChAoZ]
Exceptions und Errors abzufangen mit try, catch ist gut. Dies in einer Form zu tun, indem man in Richtung Stdout Messages, Variablen, StackTraces ausgibt ist eher ungünstig. Damit Leakt man Informationen an potentielle Angreifer. Wobei der Informationsgehalt ansteigt und das dumpen von StackTraces wirklich keine gute Idee ist. Und selbst wenn sowas nur als Hilfe zur Entwicklung angedacht ist, sowas wird gern vergessen bevor es produktiv geht. Man sollte es also möglichst nie einsetzen oder nur in einer Form, dass die hilfreichen Meldungen nur im Log des Servers erscheinen. Und selbst da sollte man noch Code vorsehen, der Loglevels unterscheidet bzw. zwichen dev. und prod., im Logfile von prod. will man aus div. Gründen keine Dumps.
 
  • Gefällt mir
Reaktionen: ni-sc
[ChAoZ] schrieb:
Was ist denn aktuell das Problem?
Du hast eine API auf deinem lokalen PC laufen (localhost:8080) und willst diese nun konsumieren über eine neue Seite. Okay... dafür gibt es 10000 Wege.

Willst du nur den API Output ausgeben?
Dann brauchst du nicht mal PHP sondern ein Tool wie Postman oder Insomnia o.Ä.

Falls es mit CURL nicht geht, weil dir die PHP Extension fehlt, dann versuch mal mit "file_get_contents".
https://stackoverflow.com/questions/959063/how-to-send-a-get-request-from-php

Lass alles im try-catch Block laufen, dann siehst die Fehler sofort.
PHP:
$result = [];

try {
    $curl = curl_init();
    curl_setopt($curl, CURLOPT_URL, "http://localhost:8080/api/v1/bases");
    curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($curl, CURLOPT_HTTPHEADER, [
        "Accept: application/json",
        "x-access-token: BCDHBFDBLCXHYA"
    ]);
    $result = curl_exec($curl);
} catch (\Throwable $throwable) {
    var_dump($throwable->getMessage());
    // UPS, hier ist was schief gelaufen -> siehe var_dump Ausgabe
}

var_dump($result);
// mach hier weiter mit schleife oder Ähnliches.
Das kommt zurück: 'string(38) "Call to undefined function curl_init()"'
curl habe ich in der php.ini aktiviert, meine php_curl.dll ist auch in meinem ext-Ordner zu finden.
 
ich glaube hier fehlen einfach die absoluten Basics, wie z.B. das Verständnis für Webserver, das Verständnis von PHP, APIs und API Calls usw. Hier vielleicht auch mal gefragt, was soll mit dem Result passieren und was ist überhaupt das Ziel außer einfach einen API Call zu tätigen und etwas zurück zu bekommen.
 
Piktogramm schrieb:
Exceptions und Errors abzufangen mit try, catch ist gut. Dies in einer Form zu tun, indem man in Richtung Stdout Messages, Variablen, StackTraces ausgibt ist eher ungünstig.
Während der Entwicklung völlig legitim.
Klar könnten wir dem TE beibringen Xdebug zu installieren, eine IDE richtig einzustellen damit man Debuggen kann, aber wenn schon Curl ein Problem darstellt, dann ist der "richtige" Weg zum Scheitern verurteilt, ohne es böse zu meinen.

Piktogramm schrieb:
Damit Leakt man Informationen an potentielle Angreifer. Wobei der Informationsgehalt ansteigt und das dumpen von StackTraces wirklich keine gute Idee ist. Und selbst wenn sowas nur als Hilfe zur Entwicklung angedacht ist, sowas wird gern vergessen bevor es produktiv geht.
Ich sehe den API Endpoint hier und einen (Access) Token, da mache ich mir um den Stacktrace einer 20 Zeiligen PHP Applikationen nun wirklich keine Sorgen, ABER... Generell hast du natürlich recht.

Piktogramm schrieb:
Man sollte es also möglichst nie einsetzen oder nur in einer Form, dass die hilfreichen Meldungen nur im Log des Servers erscheinen. Und selbst da sollte man noch Code vorsehen, der Loglevels unterscheidet bzw. zwichen dev. und prod., im Logfile von prod. will man aus div. Gründen keine Dumps.
var_dumps lassen sich im Prod-Betrieb komplett abschalten.
Das war der TE vorhat und vor allem mit seinem Wissen in diesem Bereich, sind var_dump Ausgaben (Russian Debugging) völlig legitim.

joekater schrieb:
Das kommt zurück: 'string(38) "Call to undefined function curl_init()"'
curl habe ich in der php.ini aktiviert, meine php_curl.dll ist auch in meinem ext-Ordner zu finden.
Jetzt siehst du den Fehler, welchen du schon vorher hattest.
 
[ChAoZ] schrieb:
var_dumps lassen sich im Prod-Betrieb komplett abschalten.
Das war der TE vorhat und vor allem mit seinem Wissen in diesem Bereich, sind var_dump Ausgaben (Russian Debugging) völlig legitim.
Und die aller Meisten lernen dieses Gefrickel und weil es geht nutzen sie es bis zum bitteren Ende. Ohne je die Dokumentation mal selbst zu lesen und ebenfalls ohne je für die Probleme sensibilisiert zu werden.
 
  • Gefällt mir
Reaktionen: aronlad
Zurück
Oben