Week 11: RESTful Project Part 1

Ridwan and I thought it would be fun to make an audience-controlled karaoke machine, with controls for selecting a song video, playing and pausing that video, changing the playback rate, and giving compliments to the karaoke performer.

After some fits and starts, I’m starting to get the hang of how to create a web app with HTTP requests and routes. Talking it through in class, with peers on the floor, and with ITP Resident Alejandro (see his project from last year) clarified my thinking about how to approach this assignment. Coincidentally, in helping a student with their P5 data assignment this week, I found the GIPHY API documentation (see especially the section, Technical Documentation/Specifications) to be a useful example of a clearly-communicated RESTful API.

An API describes a system to access data from a web service. Often we see this data formatted in the HTML pages of the website, but often too, we can retrieve this data formatted in JSON. And REST is a framework or style for retrieving and manipulating that data.

Whether you are asking for or updating existing data, all actions are called a request. There are four common types of requests:

  1. GET for retrieving data from the server and/or for updating a resource (because values for doing so may be included in the URL, the request params)

  2. POST for asking the server to update or create a resource using the JSON-formatted data enclosed in its message (the request body)

  3. PUT for asking the server to accept and update or create a resources using the data enclosed in its message

  4. DELETE for asking the server to delete data

From HTTP Request Methods: “The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times.”

Other resources I used this week:
The Definitive Node.js Handbook
Express Documentation
Shiffman’s Introduction to Node & Express
nodemon

ROBO-KARAOKE
Our device gives the audience control over the song selection and playback of a karaoke video on a browser window that can be projected onto a screen. It is intended for die-hard karaoke fans in a room with people with whom they feel safe and ready for a good laugh. It is best-suited for use well into the group’s party.

We envision either a physical controller or a digital interface on mobile devices. Either option, however, impacts the game mechanics. With a physical controller, the audience shares or vies for control of it. With a digital interface, each audience member accesses the controller from their own phone and blindly competes with their fellow audience members to influence karaoke video playback.

As the audience decides the level of difficulty for the singer(s), the controller includes the option to send a random compliment to the screen to cheer them on.

Jason and Roxanne will build the controller. Ridwan and I will build the server and video player.

SERVER SKETCH
I built out part of the server for our device here.

API SPECIFICATIONS

See Song List
GET /songs
returns:
{
"songs": [
"Song Title by Artist",
"Song Title by Artist",
"Song Title by Artist",
"Song Title by Artist",
"Song Title by Artist"
]
}

Select Song for Playback
GET /select/:songid
songid: choose from range of 0-4 to match the index of the song in list
returns: songid
notes: this sets playing to true and playback rate to 1

Play/Pause Depending on Current State
GET /playing/
returns: false or true

Set Playback Rate
GET /rate/:value
returns: value of video playback rate

Display a Random Compliment
GET /compliment
returns: current compliment

Current System Status
GET /state
returns:
{
'songID': ‘value as string’,
'currentSong': ‘string’,
'isPlaying': bool,
'playbackRate': ‘value as string’,
'currentCompliment': ‘string’
}

SYSTEM DIAGRAM

Screen Shot 2018-11-19 at 1.33.45 AM.png

DESIGN SKETCHES

1-1.jpg
1.jpg