UMass Lowell Dept. of Computer Science
COMP 4620 — GUI Programming II
Spring 2016 Semester, Section 201
Prof. Jesse M. Heines
Notes for Class No. 13
Review of In-Class Usability Tests and Continuing with MongoDB
Thursday, March 3, 2016
A video of this class is (or will be) posted at:
http://echo360.uml.edu/heines2016/comp4620-201.html
Handouts and Materials
Openings / Announcements / Reminders
Free course on Ember (after free sign-up)
http://campus.codeschool.com/courses/try-ember/contents
Additional free courses this weekend, March 4-6
https://www.codeschool.com/free-weekend
Class Notes
Related reading for this class: Handouts and GetMEAN: Chap. 6
Review of Alpha Version Usability Testing
Your comments on each others’ projects
- did no one review the Leung-Moran-Wong project: Music Practice Manager?
Writing a REST API (Ch. 6, continued)
Syntactic Details
Review from last Thursday’s class ...
Each CRUD operation has a URL path and optional parameters (p. 163)
- note that some of these are the same
The requests are differentiated by the method that each operations uses (or with which each URL path is called) (p. 163)
Putting these two together we get (p. 164)
When subdocuments are involved, we add the subdocument path to the URL (pp. 164-165)
New material begins here ...
Response and status codes (p. 165)
- a REST API (or any API for that matter) should always respond
- if the database call is successful, both the returned data (as JSON in our case) and a status code should be returned
- if the call fails for any reason (an error occurs), an appropriate status code should be returned
- status codes — these are standard HTTP status codes
Implementation Details
Starting on p. 167, Holmes goes through all the code to create the REST API
- students have told me that it isn’t productive for me to go through all the code, so I will not do that
- it is pretty straightforward, but there are a few “gotchas” in the book that I want to point out
- Be careful with file locations
- some are mislabeled in the book
- for example, Listing 6.1 on p. 169 is file
app_api/routes/index.js, not locations.js
- see Figure 6.4 on p. 171
- I also find it confusing that files with the same name exist in various folders
- I recommend a different naming convention to make it easier to keep the files straight and identify what file you’re talking about
- Note that in the text, Holmes defines function
sendJsonResponse at the bottom of page 170 and uses it throughout the chapter
- the problem here is that in his GitHub repository, this function is named
sendJSONresponse
- thus, if you cut-and-paste from the GitHub repository as I recommended but also type some code, be careful to use the correct function name
- Postman is discussed on page 173
- this app only runs in Chrome
- to get it, go to http://getpostman.com
- but note that the screen captures are a bit out of date
- that is, the UI has changed slightly
- We saw the
find command in our last class (p. 174)
- what does the
find command do?
- there are also two convenience commands:
findById and findOne
what do you think a “convenience command” is?- why do you think these two convenience commands, in particular, are defined?
- Given the issues that we’ve had recognizing code patterns in previous snippets, let’s make sure that everyone understands the one on page 174:
- The discussion on page 175 of how to use function
locationsReadOne is critically important
- here is the function in our API that we want to call
- note that the
locationid we need comes from the URL used to call our API function
- that is, it is one of the parameters (
params) of the request object (req)
- to get that parameter, we use the Express syntax:
app.get( "/api/locations/:locationid", ctrlLocations.locationsReadOne ) ;
- Page 176 reiterates the admonition in Figure 6.3: “Your API code must never leave a request unanswered.”
- unfortunately, some of the status codes in Listing 6.2 on p. 177 are incorrect
- I believe that the first two 404 error codes should be 400
- Remember that to find a subdocument, you first have to find its parent (p. 177)
- To limit the data returned for a found record, use the select method chained to a model query (p. 179)
- note how the methods are chained
- chained method calls are processed from left to right
- note that “the select method accepts a space-separated string of paths we want to retrieve”
- Even though I said that we’re not going to worry about geolocation, the structure of the code on page 183 is important to understand
- what, exactly, is going on here?
- Note the amount of error trapping that Holmes includes in his code in Listing 6.3 on pp. 179-180
