Being a developer in any environment requires you to understand the tools we

have for building any given application.

What do we do when we get stuck, where can we look for possible APIs that we can use?

Here's a few tips.

If you get stuck in this course, or even in your own projects, you can ask for

help in the Treehouse Community Forum.

Your fellow students can give you hints and suggestions.

In fact, students are rewarded for participating in the community, and

by giving the best answers.

Be sure to remember to embed your code, or link to the source code of your project.

Got an error, and not having much luck in the community?

There's a chance someone else has had the same issue as you.

How do you find them?

Open up your favorite search engine, and

paste in the most relevant part of the error message.

There's countless numbers of blog post, sites,

forums, newsgroups, where people post their problems, and how they solve them.

But probably the most important place you can get see what's possible with any given

language, framework, or platform is, by going to its official documentation.

In our case, it will be the node.js documentation site.

Let's take a quick look now.

Node.js is official website is, node.js.org.

Click on docs in the navigation, in of the languages and frameworks.

It may say documentation or API.

Generally, these terms are interchangeable.

API stands for application programming interface.

The documentation explains the API, or how you interface with

the objects in the language, environment, or framework that you're working in.

In other words, the API is the objects and

methods that you can use in any given environment.

In the browser,

the API is called the document object model to interface with web pages.

With node.js, the API is what you interface with the file system,

or other APIs like making HTTP requests.

Don't worry if the website looks different from how it looks on your screen.

Websites are always being updated.

As a developer, we must be adaptive to our ever changing surroundings.

Let's click on the API closest to the version of node that you've got installed,

or is in Workspaces.

Looking in the Table of Contents, there's a link to about the docs.

I want to point out the section at the bottom called the Stability Index.

Zero means you shouldn't be using this anymore,

because it's deprecated, one is experimental, and

is something that many come in the future, but it could be removed.

So you've been warned.

Whilst indexes two and three stable unlocked,

it shouldn't change, unless something serious happens.

So, you say if using these in your applications, as a developer,

you'll be making difficult decisions all of the time.

And choosing what API you should use of or another is one of those times.

But in general, the rule of thumb is to stick to stable unlocked APIs.

Now let's go back to the API docs, and

take a look at some of the things that you can do with node.js.

Listed in the table of contents are all the APIs that

come out of the box with node.js.

All should include their own stability index.

Some of the most common APIs that you'll use are the console,

which is the way to output strings to the console.

File system, these are where the APIs to read and write files are found.

And HTTP and HTTPS, for creating web servers, or

going out to the Internet to retrieve information.

Let's take a look at one example in HTTPS.

When we click through, there's a table of contents.

This is where you can skim through the possible objects, methods,

and properties related to the HTTPS web requests and responses.

Let's take a look at https.get.

The first line of code is including the HTTPS methods to

handle what requests to HTTPS, secure HTTP service.

The https.get method has a string of a URL

pointing to the secure sites encrypted.google.com.

The second argument is an arrow function.

I call back.

If you're unfamiliar with this syntax, see the teacher's notes for

some material to watch.

In our analogy before, the request is us sending out an invoice.

The call back is the client sending the payment to us.

Google's server is sending a response to us.

Res is short for response.

Because node.js is built with the non-blocking model in mind,

the application can still be doing other things, while we write for the response.

Using callbacks is a common pattern you'll see in building node.js applications.

A lot of built in node.js APIs require callback functions.

A callback function gets executed when the program is finished a particular task,

or an event has occurred.

If you build Ajax applications before, you don't have to halt your job script

program while you wait for the response from the server.

You give it a callback to run once the data has been downloaded.

If you've ever interacted with user events like mouse clicks or keyboard presses,

you don't halt the program from running until the event occurs.

You give it a callback to be executed when the event occurs.

In node.js, you can do the same thing, you provide a callback for System Events.

So, in this example,

the response has a system event called data associated with it.

Then this callback prints out a piece of data.

System events are triggered by the computer, not a user interaction.

Process.stdout.write is just using console.log to print out information.

This bit of code here responds to an error event on the request object.

When you see on method being called on an object, it's responding to an event.

You'll see this a lot in node.js.

These lines tell you the response is status code,

whether the request was successful or not.

And then any special metadata called headers was sent from the server.

If you're new to HTTP requests,

I've included some information in the teachers notes about HTTP.

However, we'll cover what we need in this course as we go forward.

As a developer,

being able to ask specific questions, short examples of your code, and

synthesize the information from a number of sources is an absolute required skill.

It may feel daunting at first, but it gets better, I promise.

It takes practice, but for

now, I'll be here to help you build these command line applications together.