Good man page on cURL: http://curl.haxx.se/docs/manpage.html

NOTES FROM CLASS:

HTTP: Stateless Protocol. With HTTP you make a request and get reply then its over. State is not maintained

URN- Universal Resource Name – the Actual file or route you are looking for URI - Universal Resource Identifiers – Lets think of everything on the net as a resource. URI is a universal way of describing these resources. This is where on the net you resource is located. The domain, but not the specific file. URL - Universal Resource Locator – the protocol + identifier+ name to get your resource: This is how do we access the information at a given place on the net.

HTTP, FTP, SFTP etc… HTTP is just one protocol to access information at a given URL/URN.

In this example: http://tigoe.net/mtt2/age_checker.php URL is http://tigoe.net/mtt2/age_checker.php URI is tigoe.net/mtt2/age_checker.php URN is age_checker.php

We looked at cURL again: curl is a program that calls URLs in linux. It can do all the basic HTTP requests, including GET & POST. It can follow redirects, it gives us data, it can return the HTML the Header and other things (see man page: http://curl.haxx.se/docs/manpage.html )

curl command in terminal can process get post pull delete requests curl on its own does a get request curl -i returns header curl -l allows terminal to follow redirect. if you include the -i it will give you headers for each hop.

basic browser request is get request

“Headers are the guts of HTTP”. Headers from an HTTP request contain different types of information, including file types or MIME (Multipart Internet Media Exception) types. Header will have Key Value Pairs separated by a colon. Look at headers, they will give you information.

Tom Curls to NYTIMES.com Gets redirected. Gets headers of stops along the way. We see that in a way you can use the information from the header as a sort of trace from the URL you enter to the URL you end up at.

Server Side Scripting Looking at backend for toms age checker program:

We pass the data for the form variables, a URN, and a request method( GET , POST)

Extra info you’ll get from the server: time sent, position, etc

In this PHP script you are passing information but you also get information back and pass on some HTML (same with many other languages)

Most server side scripts are just taking in the information they are given, doing a calculation, then formatting and returning the results. We want to look for the special variables or places where the request information is put. How do we pull it out, format it, pass it back?

POST vs GET: GET requests shows all information in the URL. POST is cleaner, form information is not displayed in the URL. POST is typically used for sending information to the server because it leaves a clean URL, and maintain easy to read & consistant formatting.

HUE LIGHTS: Client sends HTTP request to the controller which has Ethernet in and zigbee (radio) out. The lights have zigbee in. Info is sent wirelessly to the lights. Client -> HTTP -> Controller Server -> Radio to Zigbee -> Zigbee Receiver in the Lights -> Packet gets interpreted to RGB light information Client and Sever have to be on the same subnet in order to communicate. Once on the same subnet they look for each other and establish a socket connection once they are found. With devices that are open (no authentication required) information is processed sequentially on a first come first serve basis

Tom Demos Hue Light API: We can chose methods for receiving and sending information JSON (Java Script Object Notation) - In JavaScript (and JSON) functions can be variables, variables can be functions.

Representational State Transfer (REST), Hue lights as a RESTful interface:

The system operates by making HTTP requests that describe and or represent the state of the system (Lights). If we type “/light1” into the hue light API we are requesting information from Light 1 and the system will return the state of the light. In other words it will Transfer the Representation of the State of our light. Allowing us to know the state of our lights (are they on, off, what color are they displaying, etc). We can also put this information (/light1) in the browser, which will return the JSON that represents the state of that light at the time of the request. We often think about URLs as a file path. I.E. Http://tigoe.net/mtt2/age_checker.php Will take use to a server at tigoe.net that has a folder called “mtt2” which contains a file called age_checker.php But URLs do not have represent files. They can represent anything we want them to describing the state of the resource we are after. In the Hue lights example, there is no folder called /apinetworkclasslights But that route tells the server to use this information as a set of commands. This is the design of a RESTful system. Our URL represents a path to any resource that can be represented to the server or client. This information can be a file, a protocol, a script, an RGB light, etc.

Assignment: Build a RESTian interface Physical -> Web Physical -> HTTP -> Physical Web -> Physical

Igoe shows: Intel Galileo Arduino Yun Arduino Tre

2 ways to get into your Yun (other board): Wifi (ssh) or Serial.

cURL POST requests from the terminal: curl -d + url + your data

or with a text file curl -d data.text

Can we send and listen at the same time? How can we approach getting user feedback over HTTP?

One simple way is to utilize the automatic server response. Server often responds with the 200 ok. We can write a program that listens for the returning 200 and gives user feedback when it receives that message. Likewise a 400 request could give negative feedback…

For homework we can use any embedded board (beaglebone, raspberry pi, yun, Ethernet shield, etc) any software or language like temboo, spacebrew, node JS, processing, python whatever language, hardware, software you are comfortable with/ interest in. The point its to get familiar with HTTP, REST, and event based systems.