HTTP, Promises, and TDD (Week 6) - Learning Objectives

HTTP (W6D1) - Learning Objectives

HTTP

1. Match the header fields of HTTP with a bank of definitions.
   • Host: Root path of our URI (typically a domain like appacademy.io, could also be an IP address)
   • User-Agent: Information about which browser the request originated from
   • Referer: The URL that you’re coming from (such as when you click a link to a new site)
   • Accept: What the client can receive. May be expansive to accept all kinds of data, or limited, such as only accepting application/json
   • Content-*: Defines details about the body, indicating what format it is in, such as application/json or application/x-www.form-urlencoded
   • Location: A server typically adds this to a response so that the client can perform a redirection
   • Expires: When the response should be considered stale and needs to be refetched. Often used to cache a response so that subsequent requests can load directly from the cache instead of hitting the server.
   • Set-Cookie: The server is telling the client to create/update a key/value pair in its cookies.
2. Matching HTTP verbs (GET, PUT, PATCH, POST, DELETE) to their common uses.
   • GET: Direct requests. Do not contain a body, simply asking for data.
   • PUT: Update a resource on the server. Contain the whole resource to be updated.
   • PATCH: Update a resource on the server. Does not need to have the whole resource, usually just the identifier and what fields are being updated.
   • POST: Creating a new resource on the server. Usually what is generated when we submit a form, with the form’s data being passed in the body of the request.
   • DELETE: Destroy a resource on the server, such as removing a product, or logging out a user (destroying their session)
3. Match common HTTP status codes (200, 302, 400, 401, 402, 403, 404, 500) to their meanings.
   • 100s: Informational
   • 200s: Successful
     • 200 OK: received and fulfilled, typically with a body that has the requested data
   • 300s: Redirection
     • 302 Found: the resource has moved. We usually see this with a Location header, where a browser will automatically redirect the request to the new location.
   • 400s: Client Error
     • 400 Bad Request: General response that the server couldn’t understand your request. Often seen with typos, if a more specific 404 is not issued.
     • 401 Unauthorized: The resource may exist, but you’re not allowed to see it unless you are authorized. (Try logging in with valid credentials before sending the request again.)
     • 403 Forbidden: The resource may exist, but you’re not allowed to see it, even if you are logged in. Can also be seen if you’re trying to perform an action that is not allowed (such as creating a duplicate record). Maybe this is a resource that you need special permissions for, like admin access.
     • 404 Not Found: The resource doesn’t exist. It may be that it hasn’t been created, or that you just had a typo in what you were requesting.
   • 500s: Server Error
     • 500 Internal Server Error: The server tried to process your request, but something went wrong, typically there was some kind of runtime error in the server code due to your request.
4. Send a simple HTTP request to google.com
   • We can use netcat in the terminal to make a connection to a URL and send an HTTP request
   • nc google.com 80 opens our connection to google.com
   • After we make our connection, we specify the three parts of an HTTP request:
     • Request line
     • Headers
     • Body
   • GET / HTTP/1.1 creates the request-line, indicating our verb (GET), URI (/), and version (HTTP/1.1)
   • any other headers we would like (optional), such as Accept: application/json
   • body of the request (optional), such as myKey=myValue
5. Write a very simple HTTP server using ‘http’ in node with paths that will result in the common HTTP status codes.

const http = require('http');

http.createServer(function(request, response) {
    if (request.url === '/200') {
        response.writeHead(200, { 'Content-Type': 'text/html' });
        response.write('<h1>Hello, world! Status 200 OK!</h1>');
    } else if (request.url === '/403') {
        response.writeHead(403, { 'Content-Type': 'text/html' });
        response.write('<h1>This is Forbidden! Status 403 Forbidden!</h1>');
    } else {
        response.writeHead(404, { 'Content-Type': 'text/html' });
        response.write('<h1>What is that? Status 404 Not Found!</h1>');
    }
    response.end();
}).listen(8080, function() {
    console.log('Listening for requests on port 8080...');
})

Promises - Part 1 (W6D2) - Learning Objectives

Promises

1. Instantiate a Promise object

• We can instantiate a Promise object using the new keyword.
• The Promise takes in a callback that we can invoke, taking in two arguments: typically labelled resolve and reject.
  • resolve is invoked when we want to indicate our function has successfully completed. A value can be passed as the successful return value.
  • reject is invoked when we want to indicate that our function failed in some way. A value can be passed as the fail value (what would be used in a catch or the second argument to then).

  function pause(numberOfSeconds) {
  return new Promise((resolve, reject) => {
    // resolve is invoked to indicate a success, reject is a failure
    // if a value is passed to resolve, it will be caught as the first argument to .then()
    // if a value is passed to reject, it will be caught as the first argument to .catch(), or the second argument to .then()
    setTimeout(() => resolve(), numberOfSeconds * 1000);
  });
  }

2. Use Promises to write more maintainable asynchronous code
   • We can chain .then calls on Promises, ensuring that the callback will not be run until the previous statement has finished executing.
   • Prevents us from having to nest our callbacks

   // Without Promises, we have to nest our code.
   // These can get very confusing; this is a simple example, but it's already hard to tell what each setTimeout's delay is connected to.
   setTimeout(() => {
       console.log(message)
       setTimeout(() => {
           console.log(message.toUpperCase() + "!")
           setTimeout(() => {
               console.log(message + "?")
               setTimeout(() => {
                   console.log(message.toLowerCase() + "...")
               }, 1 * 1000)
           }, 3 * 1000)
       }, 2 * 1000)
   }, 1 * 1000)
   
   // With Promises, we write more code up front in order for us to have more readable and maintainable code
   // We define our promises
   function promise1(message, delay) {
       return new Promise((resolve, reject) => {
           setTimeout(() => {
               resolve(message)
           }, delay * 1000)
       })
   }
   
   function promise2(message, delay) {
       return new Promise((resolve, reject) => {
           setTimeout(() => {
               resolve(message.toUpperCase() + "!")
           }, delay * 1000)
       })
   }
   
   function promise3(message, delay) {
       return new Promise((resolve, reject) => {
           setTimeout(() => {
               resolve(message + "?")
           }, delay * 1000)
       })
   }
   
   function promise4(message, delay) {
       return new Promise((resolve, reject) => {
           setTimeout(() => {
               resolve(message.toLowerCase() + "...")
           }, delay * 1000)
       })
   }
   
   // Then we chain can chain them however we like.
   // Returning our strings from our Promises is adding flexibility to our code, allowing us to use the results however we like.
   // We replaced the complicated nesting with more modular chaining of .then
   promise1("hello", 1)
       .then(res1 => {
           console.log(res1);
           return promise2("hi", 2);
       })
       .then(res2 => {
           console.log(res2);
           return promise3("hey", 3);
       })
       .then(res3 => {
           console.log(res3);
           return promise4("what's up", 1);
       })
       .then(res4 => {
           console.log(res4);
       });

3. Use the fetch API to make Promise-based API calls

// init is an optional object argument to customize the method (default is 'GET'), headers, or body of the request
// For example, it could take the form:
    // const init = { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: '{"title": "Sir", "name": "Robin"}' }
fetch(url, init).then(response => {
    // do something with the response
    // common first action to take would be parsing the response
        // parsing json with response.json(), or text with response.text()
}).then(data => {
    // since fetch is returning a promise, we can chain on as many .then calls as we need
})

Promises - Part 2 and HTML Review (W6D3) - Learning Objectives

Promises

1. Use async/await with promise-based functions to write asynchronous code that behaves synchronously.

// Without async/await, we can use .then chains
// We use a .catch method to catch errors
function wrapper() {
  promise1("hello", 1)
    .then(res1 => {
      console.log(res1);
      return promise2("hi", 2);
    })
    .then(res2 => {
      console.log(res2);
      return promise3("hey", 3);
    })
    .then(res3 => {
      console.log(res3);
      return promise4("what's up", 1);
    })
    .then(res4 => {
      console.log(res4);
    })
    .catch(err => {
      console.error("Error encountered:", err)
    });;
};

wrapper();

// With async/await, our code looks more like synchronous code
// We use a standard try/catch block to handle errors
// In order for us to use `await` we must be in a function declared with `async`
async function wrapper() {
  try {
    console.log(await promise1("hello", 1));
    console.log(await promise2("hi", 2));
    console.log(await promise3("hey", 3));
    console.log(await promise4("what's up", 1));
  } catch (err) {
    console.error("Error encountered:", err)
  }
}

wrapper();

HTML

• Be comfortable with using the following tags. This is review/tangential material and will not be tested directly on the assessment, but if it would appear in a problem, you should know what it is doing.
• • the root element of the HTML document
  • valid child elements are and

- contains metadata for the HTML
- often will include a <title> as well as <link> and <script async> tags

• • what appears in the tab or title bar of the browser
• • allows us to link another file, we’ll often see it for our css
  • rel attribute specifies the relation of the link (“stylesheet”, less common may be “icon”, “author”, etc.)
  • href attribute specifies the URL of the linked file (can be an absolute url or relative path to file in your project)
• • allows us to add JavaScript to be run
  • can include code between tags, or provide a src
  • src attribute specifies the URL of the linked script (if this attribute is present, the