This is the curriculum for the 2019 Alpha Web Developer Bootcamp.


What is a HTTP VERB

All HTTP requests have a verb associated with them, and it is passed as part of the head of the request. There are 4 main HTTP verbs used in modern web applications

  • GET
  • POST

They are the verbs of HTTP because they describe what type of action the sender is asking the server to perform.


GET simply asks the server to return a resource to us. Most of the time when you are surfing the web, your browser is making GET requests to a server somewhere for the webpage.


POST is a request to create something. Imagine the Twitter API as an example. You can POST a request to Twitter to create a new tweet for you.


PUT and PATCH are closely related. They are requests to update a resource on a server. When you submit a form that contains your account information for a website, you are most likely making a PATCH request. Your account already existed when you went to that page, and now you are just updating it. The difference between PUT and PATCH is subtle. PUT is for replacing the resource entirely, and PATCH is for when you just want to make a few updates. It is often more correct to do a PATCH request, but they are so similar that many API's treat them as synonyms.


DELETE requests exactly what you would think. You would like to remove a resource.

Not all API's are created equal

It is up to the developer to implement the HTTP verbs within their api, and there are as many apis out there as there are opinions on how to do it correctly. Some api's only support GET and POST, lumping all the other verbs into POST. Some use PUT, some use PATCH, some support both. When you are working with another developer's api, hopefully they have documented their implementation so you know how to use it.

Pop Quiz

What would you expect the following web requests to do based on the HTTP verb, and URL?

  • GET /balloons
  • GET /balloons/4
  • POST /balloons
  • PUT /balloons/5
  • PATCH /balloons/5
  • DELETE /balloons/5

Verbs can share a resource

Notice above that verbs can share a URL. GET, PUT, PATCH, and DELETE can all operate on the same resource. RESTful interfaces work exactly like spoken language does. There is a subject, and an action, which together make up a command.


REST is a design or architecture that can be implemented on many different protocols, HTTP being the most common one. Its important not to confuse REST with HTTP. You can use HTTP without REST, and you can use REST in many more places than HTTP requests.

One of the great things about REST is that when someone tells you that they built a RESTful interface, you already know a lot about it. You know that it will be using the verbs, and that it will have resources represented by URLs or specific addresses.

Postman from LEARN on Vimeo


Postman is a developer tool to work with apis. You can install it as a Chrome extension, or directly from their website.


Today we're going to take a deeper dive into JSON and how to work with it within the server and browser application. JSON stands for JavaScript Object Notation, and is very efficient in storing and transporting data across the internet. You may recall our exercise parsing the NASA Near Earth Object api to build a web page. We just covered the main points on how to deal with data in JSON notation. After today, you'll understand fully how to use and debug JSON data.

What is JSON


You can checkout JSLint here

Parsing JSON


HTTP Response Codes

Part of the HTTP protocol is issuing a response code with every response. This ensures that there is at least some understandable piece of data, no matter what else the response contains. These codes are specified by the W3C, and all webservers everywhere, along with all the web browsers agree on them. You'll eventually learn some of these and throw them out like they are common knowledge: "So I just got a 404 back on that request.", and to your web developer friends, they will be. There are some codes that you will never ever use, and even some codes that are just for fun. Don't worry about memorizing them, you'll remember the important ones. Just learn to recognize them when you see them, and be able to look them up when you need to.

General categorization of HTTP codes

All response codes are 3 digits long, and the first digit is meaningful. If you only know what the first digit meant for response codes, you'd already know a lot about what that code means.

  • 1xx : Information about connection that is still in progress
  • 2xx : Successful response
  • 3xx : Redirection
  • 4xx : Client side error
  • 5xx : Server side error

The Internet is not without a sense of humor.

Remember when I said there were a few joke response codes in the specification? Take a look at 418, its a valid response code:

  • 418 I'm a teapot (RFC 2324) This code was defined in 1998 as one of the traditional IETF April Fools' jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. The RFC specifies this code should be returned by teapots requested to brew coffee.[49] This HTTP status is used as an Easter egg in some websites, including[50]

Webservers can send their own codes.

Some webservers like Apache and Nginx may send their own codes as well. You'll want to watch carefully for these, as they are less common and could cause bugs in your code. Check this Wikipedia article for more information.

HTTP Requests and Responses

When working with Express on the server, and an AJAX request in a web application, communication between the two is organized into a request, and a response. Each side deals with both to complete the exchange of data. Additionally, Express and the browser transform the request into an internal object that they are free to append data to as the request makes its way through the program. Recall the discussion on Middleware in Express.


During each step through the middleware, the request and response are available for the middleware to read, and add to, or remove from. Requests and responses are objects that maintain their own state as they are passed through the application.

Requests in Express

You will work with requests most often on the Express side. A request has a lot of data associated with it by the time it makes it to your controller action. Most of it you only need in rare situations. There are two pieces of the request that are useful on nearly all actions however, those being the parameters of the request, and authentication data. On POST/PUT/PATCH requests we also look into the body of the request to find the data passed to us.

When a user submits data via POST or GET, there will often be params associated with the request. We can access those on the request object, and use them to customize the actions response.

If our controller has an action like this:

app.get('/', function (req, res) {

Then it will pass back any params that the requestor provides. The params object is a regular old Javascript object, so if we were to make a request like so:

GET http://localhost:3000/?search=kittens&page=3

Then we'd expect to get a response back that looks like:


And expect to see

search kittens
page 3

if we watched the output from the running process.

Responses in Express

A response object is where we can build up the response that will eventually be sent back to the requestor. As developers, we're generally concerned with the status, and the body of the response. The status is where the response codes come into play. If the request was successful, we can set a 2xx type of response code. If we'd like to redirect the requestor to another url, we set status to a 3xx type code, and so on. In the body of the request, we put our payload. For API requests, we often use response.send(<payload>). If we're serving a webpage, we typically use response.render() which invokes a template to construct the HTML response.

Responses in a Web app

Once the server has sent off the response, its the application's turn to process it. We've used the built in 'fetch' interface to request and process data sent back to us. You may want to review Fetch by watching this video again:

When we process a fetch response, we have access to the status, body, and json among other attributes. Additionally, fetch will return success or failure based on the response status returned to it:

  //return the part of the response we're interested in
  return rawResponse.json()
}).then(parsedResponse) => {
  //do what we need to with the parsedResponse, a JS object in this case
}).catch(function(error) {
  console.log('There has been a problem with your fetch operation: ' + error.message);

HTTPS and SSL from LEARN on Vimeo

HTTPS and SSL Certificates

Most websites these days is served over HTTPS, which means its secure. As a web developer, eventually, you'll want to also serve your website over SSL. Its not mandatory, but if you are dealing with user information, or you want Google to rank you high in their searches, then it really is mandatory for you.

How do you serve content over SSL?

In a nutshell, to serve content over SSL, you need a certificate that verifies you, as the server of the content are who you say you are. Then the browser and server share a secret they use to encode and decode information.

How does this keep the user safer?

User data stays safe due to SSL because it protects their data from what is known as a "Man-in-the-Middle" attack. This type of attack is when a malicious actor injects itself between the server and user, and just inspects traffic as it passes through. The user and server may never be aware that they are being attacked like this, but all information that is not SSL encoded will be observable by the attacker, credit card numbers, passwords, secrets, etc... Not good! SSL protects users by encoding all data in the request which only both sides can decrypt because they share a key.

DNS from LEARN on Vimeo

What is DNS?

DNS stands for "Domain Name Server", and in a nutshell, it is what translates an IP address into a human readable name, and vis-versa.

What is an IP address?

What is an IP address you ask? IP address are the unique address of every device anywhere that is reachable on a network of computers, the internet being the largest network of them all. And IP address looks something like: You're computer has an IP address right now, as does your phone if it is connected to wifi. These may not be addresses that are reachable via the Internet, but the network in your home or office works roughly the same as the Internet does as a whole

What is "localhost"

When you started developing, you may have wondered about the "http://localhost:3000" address that you were always using to connect to a local development server. What is "localhost". Localhost is a special name provided your computer to reference itself. It means "Look at my local network, and ask myself to handle this request".

What does the rest of the url mean for "http://localhost:3000"?

Your next question regarding "http://localhost:3000" may be about that number (3000) at the end. What does that mean? The number at the end of the domain name is the port number to make the request on for that particular server. A port is simply an access point into that server. Computers need ports because they can have many different types of conversations over a network, and the computer needs to know what language to speak to each of the different partners it is talking to. For example, databases communicate on their own port because their communication protocol is very particular to them. (Postgress uses 5432 by default).

You can actually setup any service to listen on any port on your computer, and if something else isn't already listening on that port, you'll be just fine. There is one caveat to that last statement. On a Unix machine like your Mac, or web servers, all port numbers below 1024 are privileged, meaning only the root user can connect through them. All web traffic runs on ports 80 (non-ssl) and 443 (ssl), so these are privileged, and need special permissions to use.