TODO

Built with: 8b98e5a296d95c5e832db0756828e5bec31c6f50 (0.5)

REST in Practice
RESTful Web Services
RESTful Web Services Cookbook

tcpdump -i lo0 -w packets.pcap tcp


* Switch to using pipes:
	- https://github.com/mozilla/rust/issues/2830
	- https://github.com/mozilla/rust/issues/4284
* Should add an image to sample server (or just add support for favicon.ico)
* Log client ip, method, url
* Need a way for users to generate URLs:
	- also need to encode them if they have bad chars
* Make sure that the date header is OK. See section 3.3.1
* Post should return 200 or 204
* Put should return 200 or 201 or 204 (see 9.6)
   - could set status to zero and assert that it is set
   - or maybe use a status enum
* 201 requires location header
* Review status 411 and 415
* Should be a way to configure number of threads per connection
	- rust-socket and (I think) uv will create a single thread for each connection
* Work on http support:
	- timeout connections
	- handle continue, 8.2.3
	- methods are documented in 9.0
	- accept-language
	- status 300
	- 13.2.1 says expiration may be in the past
	- should headers be typed?
	- 14.1 has headers
* Add better pipelining support:
	- make conn_config sendable
	- use a thread pool to cap number of outstanding items in the pipline (see spawn_threaded_listener)
	- tasks will need to communicate back with the main connection task
		response, sse info, maybe settings
	- probably want to process non-idempotent methods in the connection task (tho, per the
	  rfc, clients should not pipeline these)
* Caching
	- chapter 6 has good info
* Content negotiation should use quality values, see section 3.9
* Tween support could be cool.
* Make sure examples are well commented.
* Look at some python or haskell web servers.
* Look at:
	- hal, rest-style json: http://stateless.co/hal_specification.html
* Work on restbucks example.
* Handle expect request header
* Talk about architecture.
* Servers need to handle Connection: close in requests

* Allow for multiple roots.

/Users/jessejones/Documents/Developer/rust.rtf
/Users/jessejones/Documents/Developer/web.rtf
http://www.w3schools.com/html5/html5_reference.asp
http://reference.sitepoint.com/html/img
http://htmldog.com/reference/htmltags/


request: GET / HTTP/1.1\r\n
Host: localhost:8080\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip, deflate\r\n
Connection: keep-alive\r\n
\r\n


REST		http://kellabyte.com/2011/09/04/clarifying-rest/    http://codebetter.com/glennblock/2011/05/09/hypermedia-and-forms/
1) Each request from the client to the server must contain all of the data that is necessary to handle the request
2) The data within a response to a request must be implicitly or explicitly labeled as cacheable or non-cacheable
3) Each layer cannot see beyond the immediate layer with which it is communicating with
4) Uniform interface
4a) Each resource has a URI and is access through a defined set of HTTP methods (GET, PUT, POST, DELETE)
4b) Each resource can have one or more representations. Such as application/xml, application/json, text/html, etc
4c) Self-descriptive messages: Requests and responses contain not only data but additional headers describing how the content should be handled
4d) Hypermedia as the engine for application state

A REST API must not define fixed resource names or hierarchies (an obvious coupling
of client and server). Servers must have the freedom to control their own namespace. 
Instead, allow servers to instruct clients on how to construct appropriate URIs, such 
as is done in HTML forms and URI templates, by defining those instructions within 
media types and link relations. [Failure here implies that clients are assuming a 
resource structure due to out-of band information, such as a domain-specific 
standard, which is the data-oriented equivalent to RPC's functional coupling].