REST and Web Services (Fri Nov 3, lecture 26)

Homework due for today

Legend: : Participation | : Early | : PDF | : Portfolio | : Zipped

  1. RORT: Read Ruby on Rails Tutorial ([RORT]) Chapter 10, “Updating, Showing and Deleting Users”. YES: We skipped a chapter. In this chapter we continue developing the big example, by adding logic to update users. Now we gradually move from authentication to authorization, which in a way is much simpler.

    As usual I really encourage and ask you to go through the code samples and actually type them in. You will see that it really helps your understanding and will assure your success in this course! Use your resources: the TAs, the class mailing list, stack overflow, google and push through to success! When you are done, go to Latte and answer these warmup questions:

    • What is a before_action? Try to be precise (but the answer can be expressed in two sentences.)
    • What does this css selector do: .users { ...
    • What are “strong parameters” and what is their purpose? What security risk are they meant to combat?
    • Are there one or two things you are still confused by? Code that you’ve written which is pure magic and meaningless to you? If not, what one or two things were the most memorable about your reading? Deliverable: Do the warmup in Latte and submit by 8am on the day of class.
  2. Showcase Day Script: Design the demo script for Showcase Day. It might seem early for this, but it is not! This script should drive the prioritization of your work over the next 6 weeks, which is all we have left before Showcase Day. You will have 8 minutes for the presentation, so the demo itself will probably only be about 5 minutes long. It needs to be carefully scripted. Take care in thinking this through! The best demo scripts “hook” the viewer with an interesting, novel bit. They also tell a story, e.g. “Let’s say I’ve not used by bicycle in 2 years and would like to get rid of it, and maybe exchange it for something else.” Your demo script is a series of bulletted steps that are meant to be followed during the demo. Meet with your team and discuss what the demo script should be and choose one of you to write it.Team Deliverable: Demo Script, as pdf
  3. Optional Intereting reading if you want to delve deeper: * What Restful actually means

Discussion

  • Lets look at some Demo Scripts
  • Stories
    • About being “different enough”
    • About dealing with different abilities on your team
    • What exactly will the functionality do?
    • About the Calendar
    • You cannot be coding the UI in any detail without those
    • Explain the CLI analogy

SOA and REST and Services

What is a web service?

  • Consider this web page: Olin College Engineering Courses
  • What would “TeachBack” do if it wanted to have a list of courses pre-populated with a college’s courses?
    • Grab all the text curl http://www.olin.edu/course-listing/ > olincourses.txt
    • Write a program to parse that page and then load the results into a database.
    • This is called “scraping” and usually that would violate a copyright
  • Server can also deliver information in “machine readable” formats (such as JSON or XML)
  • The term “API” is used to describe the permissable ways that one program can call another, such as a library
  • Web Service API is when this is between servers on the internet
Protocols
  • This can be done with many different standards and formats and protocols
  • Discussion: What are some of the big differences between calling a gem’s API and calling a web service API?. Performance? Error handling and recovery? Security? Cost sharing?
Pause to look at the big picture
  • Servers on the internet, anywhere, can be called as objects and methods
  • Resources of all kinds can be offered to clients with no coordination
  • The internet becomes a huge, amazing Operating System

One level deeper

RPC - Remote Procedure Calls
  • Imagine a procedure (method): get_horoscope(date, sign) => String, so for example: get_horoscope("march 22, 2015", "aries") which returns a sentence of text (not html!)
    • I could use it to improve my calendar app to optionally display the user’s horoscope
    • Or, I could use it to create a twitter “robot” to answer a tweet with my horosc
  • What would it mean to call it between two computers?
  • What would it mean to call it between two computers over the internet?
  • How would you approach it?
  • REST - A different way to think about RPC
REST based on HTTP: Mini review
  • HTTP Verbs: GET (HEAD), PUT, POST, DELETE.
  • Think of everything in terms of a ‘resource’ that is being manipulated
  • For example, GET means get a representation of the resource marked, e.g.
    • GET http://www.facebook.com/user/pitosalas
    • GET http://www.facebok.com/users
    • GET 0.0.0.0:3000/cards/1.xml
  • Some things are harder to fit with the model
    • What might a horoscope service look like as REST?
    • The ‘resource’ here is a single fortune
    • http://myhoroscope.org/fortunes/1
    • http://myhoroscope.org/fortunes
    • http://myhoroscope.org/fortunes?date=mar-15-2025,sign=scorpio
    • http://myhoroscope.org/fortunes/random
  • Note fortunes/random, random is not exactly identifying a resource; but close enough.
  • What if caching was done strictly by url?
    • Two advantages:
      • some rhyme or reason on how to build urls and
      • make logical use of url space
      • Different ‘representations’ possible: html and xml, but others too, say csv or video
      • Big one: Standards allow caching in the cloud. But what about ‘random’ case? TTL!

Look at next class