Calling API

I am calling external API like this

$response = curl_exec($curl);
echo $response;

I can see the data but it doesn’t look formatted when i look at it in the browser nor when I receive in different JS file like this

.then(response => response.json())
.then(response => processData(response))
.catch(error => console.log(‘error’, error));

function processData(myData) {

“Doesn’t look formatted” doesn’t give anyone enough information to help you. What’s actually wrong with it? What have you tried to fix the problem? What does the API documentation say about the format of the returned data? Can you show an example of what it returns to you (with personal information disguised, of course) against what it should be returning? What if you var_dump($response);, does that give any clues?

I didn’t know how to explain better than “not formatted”. It was very hard to read that’s the best I can explain but this worked for me and I was able to pass this to JS and read it from there.

$data = json_decode($response, true);
$formattedJSON = json_encode($data, JSON_PRETTY_PRINT);
echo $formattedJSON;

Why don’t you determine the structure and content of the data returned from your fetch request by doing?

    .then(response => response.json())
    .then(response => {
        //... your other code
    .catch(error => console.log('error', error));

Bit off-topic but if you plan on using apis on a regular basis then maybe take a look at Guzzle or Symfony HttpClient libraries. They can save you a great deal of effort. Especially for serious apps where error handling and whatnot becomes important.

Using a library for everything has nothing to do with being serious. I avoid external libraries as often as I can to not be dependent on other developers or companies where I never know what comes up their mind in the next year…

1 Like

That’s not an argument not to use those libraries but to abstract away from them. That is, create your own interface for an HTTP client and create an implementation that uses guzzle, or Symfony HTTP, or whatever.
Then, if the package doesn’t work for you anymore for some reason, simply create a new implementation of your interface and you’re done.

That’s the whole point of clean architecture, hexagonal architecture, etc. Use what dependencies you like, but keep them at arms length so you can easily replace them if need be.

(of course this only works if you also apply the Dependency Inversion principle, the D in SOLID)

Not so sure I would create my own interface up front for something like this. Not an easy thing to do properly. I happen to use the Symfony library. If in some future universe Symfony disappeared then I’d probably just keep the existing Symfony interface and re-implement using something else.

above code i posted worked for me. When I said “was not formatted” i meant it looked like a long string in my console as opposed looking formatted where you see in your console on name of the property in purple color and values in blue.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.