Let the tests drive your development or write your tests after. The choice is up to you! As for the testing tools use:

• mocha
• chai
• supertest
  • supertest is built upon superagent so these docs will be helpful as well

You will be building the core of a Content Management System (CMS). You will be able to create, edit, and remove content. This project will have two types of content, which will be referred to as "Resources" below, Articles and Products. For each resource you will be creating two sets of routes, a set of Endpoints which respond to POST, PUT, and DELETE methods, and another set which will serve HTML content such as a directory listing, and form for editing a resource, and a form for creating a new resource of a certain type.

Almost every website boils down to managing content.

Build an application which will have 2 resources: Products and Articles. Each resource will have an implementation of CRUD (create, read, update, delete) and will be RESTful. You should make use of Express' Router module to keep your code organized. Routes go in a directory called routes.

In addition, you will also have additional routes which will render HTML to the user. You will harness the power of the Handlebars Template Engine with express using handlebars-express to build your templates and have them be dynamic. These templates should go in a directory called templates.

Each of your resources will have its own module in charge of its own data. This module should have helper methods for retreiving data. Keep these files in a directory named db.

note: we are not using a database, having a folder called db. Later we will come back to this exercise and integrate a database. With tests already written and a db module, the refactor should go smoothly.

Here is a loose example of a module you'd build for ./db/articles.js.

Project Structure Example:

/products

• POST creates a new product
  • The incoming request will look like this: { name: String, price: String, inventory: String }
    • from this request you will save your data as { id: Number, name: String, price: Number, inventory: Number }
      • id is a unique identifier for this item. You will generate this on the server side and it will be used to access specific products with it
    • If successful then redirect the user back to the /products route.
    • If not successful then send the user back to the new product route, /products/new and some way to communicate the error back to the user via templating.

/products/:id

• PUT edits a product. Finds a product in a collection with the same id value and updates the information.
  • The incoming request will look like this: { id: Number, ... }
    • ... represents a field to be edited for example: if the server was sent { id: 12, name: "Water Bed" } the server will find the product with an id of 12 and change the name property to be "Water Bed".
    • If successful then redirect the user back to the /products/:id route, where :id is the product that was just edited, so that they can see the updated resource.
    • If not successful then send the user back to the new product route, /products/:id/edit and some way to communicate the error back to the user via templating.

/products/:id

• DELETE removes a product by its id.
  • If successful then redirect the user back to the /products page and some way to communicate to the user that this action was successful.
  • If not successful then send the user back to the new product route, /products/:id, where :id is the product that was just edited and a message that this action was unsucessful.

======

Routes below will output html generated from our template engine. Inside of your templates directory you should have the templates below in a directory called products

/products

• GET responds with HTML generated from your template which displays all Products added thus far.
  • file name: index.hbs

/products/:id

• GET responds with HTML generated from your template which displays the Products information for the product with the corresponding id.
  • file name: product.hbs

/products/:id/edit

• GET responds with HTML generated from your templates.
  • The HTML should contain a form (with values already pre-filled?) so that a user can update the information for a product. This form points to your server's route for editing a product.
• file name: edit.hbs

/products/new

• GET responds with HTML generated from your templates.
  • The HTML should contain an empty form which a user will be able to create a new product. This form points to your server's route for creating a new product.
• file name: new.hbs

/articles

• POST creates a new article
  • The incoming request will look like this: { title: String, body: String, author: String }
    • from this request you will save your data as { title: String, body: String, author: String, urlTitle: String }
      • title is a unique identifier for this item.
      • urlTitle is similar to the title that was passed in but instead is a URL Encoded version. Javascript has a native way to url-encode strings. example: If given a title of "The Best Magpie Developer of 2016", its url-encoded equivilent is "The%20Best%20Magpie%20Developer%20of%202016".
    • If successful then redirect the user back to the /articles route.
    • If not successful then send the user back to the new article route, /articles/new and some way to communicate the error back to the user via templating.

/articles/:title

• PUT edits a product. Finds an article in a collection with the same title value and updates the information.
  • The incoming request will look like this: { title: String, ... }
    • ... represents a field to be edited for example: if the server was sent { title: "The Best Magpie Developer of 2016" } the server will find an article with a title property to be "The Best Magpie Developer of 2016".
    • If successful then redirect the user back to the /articles/:title route, where :title is the article that was just edited, so that they can see the updated resource.
    • If not successful then send the user back to the new article route, /article/:title/edit and some way to communicate the error back to the user via templating.

/articles/:title

• DELETE removes an article by its title.
  • If successful then redirect the user back to the /articles page and some way to communicate to the user that this action was successful.
  • If not successful then send the user back to the new article route, /article/:title, where :title is the article that was just edited and a message that this action was unsucessful.

note: The title property is mandatory. If no other key is present then update the title.

=======

Routes below will output html generated from our templates. Inside of your templates directory you should have the templates below in a directory called articles

/articles

• GET responds with HTML generated from your template which displays all Articles added thus far.
• file name: index.hbs

/articles/:title

• GET responds with HTML generated from your template which displays the Article information for the article with the corresponding title.
  • file name: article.hbs

/articles/:title/edit

• GET responds with HTML generated from your templates.
  • The HTML should contain a form (with values already pre-filled?) so that a user can update the information for an article. This form points to your server's route for editing an article.
• file name: edit.hbs

/articles/new

• GET responds with HTML generated from your templates.
  • The HTML should contain an empty form which a user will be able to create a new article. This form points to your server's route for creating a new article.
• file name: new.hbs

Here are some middleware code for you to implement.

Analytics Tracker

• Scope: All incoming requests.
  • log to a file all uri that are requested. we need each request on its own line
    • format: [method] [uri] [timestamp]
    • file location: all logs should go into a directory called logs and end with the .log extension
    • file name: the logs should be separated per day, please figure out a way to create a nice file name which displays date. e.g. 2016.01-17.13-45-06.log

Payload Validation

• Scope: Each Resource having its own validator.

Check headers on Articles

• Scope: Incoming requests to any /articles route.
  • must have the header version: 1.0
    • if not respond back with { "error": "bad headers" }

MAKE IT PRETTY