HTTP Design Exercise

HTTP (HyperText Transfer Protocol): request-response protocol, sent using TCP/IP sockets.

  • A client sends a request message to a server, and the server returns a response message.
  • Initially designed for fetching Web pages (browser is client), but now used for many other purposes

Each request described with a URL that specifies an operation and parameters, such as:

http://www.foo.com:8080/friendships/create?my_id=100&user_id=200

Fields of URL:

  • Scheme (http:): identifies protocol used to fetch the content.
    • http: is the most common scheme and is the only one you need to consider
  • Host name (//host.company.com or //localhost): name of the machine running the desired server.
  • Server's port number (8080): allows multiple servers to run on the same machine. Normal Web servers usually run on port 80 (the default).
  • Hierarchical portion (/friendships/create): identifies a particular request, such as create a new friendship.
  • Query info (?my_id=100&user_id=200): provides parameters for the request

Sample request (see slide):

  • First line contains method, URL (hierarchical portion and query), protocol version
    • GET method: read information from server. Should have no side effects.
    • POST method: uploads data from the browser to the server (typically form data), returns information from the server. Likely to have side effects.
    • There are several other methods defined besides these two.
  • Headers: name-value pairs providing various information that may be useful to the server (these are not method-specific parameters; those are in the query data).
  • A request can also contain data following the headers
    • GET method doesn't have any data
    • POST method may include additional parameters in body, in the same format as in URLs (my_id=100&user_id=200)

Sample response (see slide):

  • First line contains protocol version number, numerical status code, textual explanation.
  • Headers have same general format as for requests
  • Blank line separates headers from response data.
  • Response body is in JSON format in this example.

URL encoding:

  • If a query value contains any character other than A-Z, a-z, 0-9, or any of -_.~ it must be represented as %xx, where xx is the hexadecimal value of the character.
    • " " becomes %20
    • "&" becomes %26, etc.
    • Example: 
      /statuses/update?status=Stuck%20in%20traffic
    • When extracting information from URLs, you must reverse the escaping.

Divide into groups, design APIs for a general-purpose Http class (and other supporting classes, if needed)

  • Http class should make it easy to write a server that handles HTTP requests:
    • Implements the HTTP protocol
    • Provides access to information in requests
    • Helps with formatting responses
    • Goal: hide as many details as possible, make it easy to write servers.
    • Think about what will be common across all servers, what will be different for each server.
  • Must handle incorrectly formatted requests in a reasonable way (i.e., clients may be bogus).
  • Can assume that calling code (in the server) is correct.

What to produce:

  • Short list of what information is hidden in the Http class, what is visible to callers
  • APIs for public methods
    • Be sure to think about exceptions
  • Don't write code for method bodies