Add overview to README.

README.md

@@ -26,6 +26,38 @@ route resulting in the string `Hello, 58 year old named John!` being sent to the
 browser. If an `<age>` string was passed in that can't be parsed as a `u8`, the
 route won't get called, resulting in a 404 error.
 
+## Overview
+
+Rocket employs code generation to remove the need for boilerplate involved with
+parsing requests and request parameters, prevent invalid and/or incorrect
+requests from invoking a user's request handler, and  allow the user to define
+what is valid and/or correct.
+
+Rocket uses type _guards_, or _constraints_, on request handlers to
+accomplishing it's safety and correctness goals. In Rocket, handlers are _only_
+invoked if all types that appear in the request handler's argument list can be
+derived from the incoming request.
+
+In their simplest incarnation, guards can be types expected of parameters in a
+matched path. This is illustrated in the previous example where the `hello`
+request handler is only be invoked if the dynamic path parameter `<age>` parses
+as a `u8`. Guards can also be derived directly from a request. For instance, you
+can define an `AdminUser` type that can be derived only if the proper cookies
+were sent along with the request. Then, by simply including the type in a
+handler's argument list as follows:
+
+    #[get("/admin/post/<id>")]
+    fn admin(user: AdminUser, id: isize) ->  { .. }
+
+you can be assured that the handler will be invoked _only_ if an administrative
+user is logged in. Any number of such guards can be included. For example, to
+retrieve the request's cookies along with the admin user, simply include the
+`&Cookies` type in the argument list:
+
+    #[get("/admin/post/<id>")]
+    fn admin(user: AdminUser, cookies: &Cookies, id: isize) ->  { .. }
+
+Full documentation about built-in request guards is coming soon.
 
 ## Building