JSON and Intermmediate Challenges Stuck

Hello, I have just finished the JSON challenges and started the “Build A Random Quote Machine” but I have no idea how to use JSON or the API’s. I am really confused. Any help would be much appreciated. Thank you.

was thinking of the most understandable way to explain it .
try this :
https://api.github.com/users/petrgazarov open this link in your browser you’ll see json file , containing info from github database (i suppose))), you can access this data with javascript , use parts of it etc API provides you tools for using other site’s features. eg you cannot type just any gihub link and get this info,
check out another simple tutorial too

that’s where i took the first link , might help as well
i would really love to know if that helped and if it didn’t then what did)

1 Like

thank you, it was helpful but I am still pretty much confused with the whole idea of api’s and how I can use them. However, thank you very much for your help.

  • for your quote machine you’ll need quotes and names of authors , you can hardcode them of course ( thats what i did)), or you can use api of some site with quotes and API( tools/interface to get them to your app), get this info as a json file and show them in your app
    eg https://quotesondesign.com/api-v4-0/ or any other
    to interact with API you need to compose a link like one you saw before it consists of endpoint (in that example it was https://api.github.com) followed by request papameters specifying what info you actually want to get (/users/petrgazarov), and this whole thing is a part of API, if github didnt have API you wouldnt have had this possibility
  • with twitter api you can put together a link which when opened gets you to a new post twitter page where you can compose a new tweet and post it, might seem useless but you can prepopulate it with anything (eg some info from your site)
  • you want to show all repos names of that github user on you page , you could copypaste forever but you have API https://api.github.com/users/petrgazarov/repos , you get the whole list and extract names or descriptions or whatever comes to mind voila )

those are just few examples , main idea here is using another site features on ur site/in ur app

sigh guess im not that good at explaining stuff as i thought i was :smirk:

1 Like

wooow that reply was totally amazing. it became crystal clear for me. Thank you very much Annestezia. You made me understand everything!! Thank you again!! Have a nice day!! :smile:

1 Like

Im really happy if that helped! :grin: Have a great day!:vulcan_salute:

1 Like

What these challenges are trying to get you to understand is one of the key usecases for JavaScript on web pages, which is to making asynchronous HTTP requests (AJAX requests).

[following is a bit of a simplification, but hopefully you get the idea]

So an HTML web page is just a text file. That text file is at a location on a computer, somewhere. That location has an address, a named identifier called a URI. If we include the protocol - https for example - it’s called a URL. So for example: at the URL https://github.com/DanCouper is a text file that contains some HTML. When you go to that location using a browser, the browser can turn that HTML into a pretty-looking web page.

JSON is another way of writing text files. It’s much simpler than HTML. It’s for structuring some arbitrary data in a sensible form that can be easily read and understood by either a human or a computer. It’s extremely simple, deliberately so: I am not exaggerating when I say this - this webpage explains the language in full, there is nothing else to it: https://www.json.org/


Going back to GitHub: GitHub has, in parallel to the HTML files that it generates, a set of JSON files it generates which contain essentially the same information. The URL for these is slightly different: https://api.github.com/users/DanCouper, but if you open that in a browser, you should be able to see (if you sorta squint at it a bit) that the page has kinda similar information - no styling or anything, just data, mind.


Sometimes, you want to go to a web page, sometimes you just want the information. And the latter case is what the challenges explore.

So lets say you wanted to make an app that let you type in a person’s name, and got some information about their projects from GitHub. You could just have an HTML page with some links - that works fine, as you would expect, but a user of your app would have to keep clicking back and forth, and the info would be hidden amongst loads of other stuff you don’t want them to care about.

Say you would like a fancy search box for users, and have some given user’s info pop up underneath. What an AJAX request lets you do is make exactly the same HTTP request you would do by putting a link in there, but instead of the browser actually going to the page, it just fetches the text file at that location. You can grab info from that text file and use it on the page the user is alread on. In this case, you want JSON, not HTML, because it is much easier to get data out of a JSON file than an HTML file.


So lets set this up - all I’m going to do is list how many repos a user has. The full code is here:

You can ignore the CSS, I’ll go through the JS line-by-line below.

The HTML is very basic:

<label for="repo-checker">Enter a GitHub username to check how many repos they have!</label>
<input id="repo-checker" />
<p id="repo-count"></p>

And the JS is as well, but it needs some explanation:

I keep a reference to the input field:

const input = document.querySelector('#repo-checker');

And a reference to the area I want to print the output:

const output = document.querySelector('#repo-count');

Then, what I want to do is listen to the input field. Every time a user types something,
I’m going to run a function called repoChecker that will make the request. The input event means the event fires every time anything changes in the input field, so this will fire the function every time a character is typed or deleted from the field:

input.addEventListener('input', repoChecker);

And this is what the repoChecker function looks like. The syntax might look slightly wierd, but this is the simplest possible way to demonstrate, so stick with me; it’s an async function, so we’re telling the JS engine that this is asynchronous:

async function repoChecker(e) {

I grab the value of the event target - i.e. the value in the input field

  const username = e.target.value;

And I attach that to the url of the Github API URL, using a function called fetch that makes an HTTP request. If you remember, that URL is an identifier for (hopefully) a text file, in the form of JSON. So if I’ve typed the letter D, the url I give to fetch looks like https://api.github.com/users/D, and if I’ve typed DanCouper, it looks like https://api.github.com/users/DanCouper.

You can go to those links in the browser, they’ll work just fine. But as I said above, the aim is to get the data without reloading the page, which is what the AJAX request does.

  const req = await fetch(`https://api.github.com/users/${username}`);

fetch has a method to decode JSON into a JavaScript object, unsurprisingly called json(), so that you can work with it easily. So I decode that text file:

  const data = await req.json();

Then I know that the number of repos is recorded under a key called public_repos - I can see this if I go to https://api.github.com/users/DanCouper - and I print that into my output area. Note that the data.public_repos || 'No' is there in case the request doesn’t return anything - it’s saying “print the value of public_repos OR print No”

  output.innerHTML = `${data.public_repos || 'No'} repo/s found for user ${username}`;
} 

So that’s very basic. The GitHub API is excellent and very easy to use. Most other APIs…well…they aren’t. The API is a set of identifiers (URLs) that refer to the location of resources, and in terms of how you go about implementing that there are a million and one ways to structure things. An API may only allow getting information - this is pretty easy. But it may also allow posting information - for example, adding comments to an article, replying to a topic on a forum, and so on - you still have a URL to hit, but you send it information (often in JSON form again) that then goes off and gets parsed and saved in a database somewhere. You can delete resources or modify existing resources, it all depends upon what has been implemented at the server end.

Very common is the need for a key to let you access the resource. You’ll go to the providers website, register, and you’ll be able to get a key, which you then add to the URL when you make the request to identify yourself as a trusted person.

There are a load of other things to consider, but hopefully that gives a bit of a thousand-foot-up view of some of what’s involved.

2 Likes