Now that we have some solid concepts of what we're going to implement,

let's begin building the interface.

I'm not talking about the visual user interface.

I'm talking about the I in API or application programming interface.

In other words, we need to describe how the program talks with or

interfaces with the service we're building.

The interface to our API is made up of URL patterns.

Each URL pattern is known as a route.

Planning routes is an important step.

You don't want to make any changes once you launch your API,

as this would break applications that would rely on the data from API.

Let's look at an example URL, example.com/about/index.html.

This URL is the route to the index.html file in the about

folder located at the example.com domain.

This is why we call our URLs routes.

They route us to a specific resource location.

API routes follow the same logical structure

where the slashes describe the nested resources.

Resources to the left of each slash own the resources to the right.

If we start with our APIs most general root resource,

we can naturally build towards the dependent resources as we go.

Because we can't answer a question that doesn't exist yet, it makes sense for

our route resource to be a question.

Our best route is slash questions.

Notice it's questions plural and not question singular.

This indicates that the route provides access to

all the questions in our database.

This is a GET route which lets us read questions.

We need to post to the route /questions to create a question.

To read a specific question we can have the URL pattern of /questions/:id.

We can access a specific question by its ID.

This is a get request to this route and should return a single question.

We are going to be implementing the editing or

the deleting of questions in our API.

If you wanted to do either of those things you'd have to go into the database

manually and perform those actions.

Now that our question routes are complete let's build the answer routes next.