diff --git a/build/2.0/mkdocs/search_index.json b/build/2.0/mkdocs/search_index.json
index 4391af97..0d9be6d4 100644
--- a/build/2.0/mkdocs/search_index.json
+++ b/build/2.0/mkdocs/search_index.json
@@ -497,7 +497,7 @@
         }, 
         {
             "location": "/vapor/controllers/", 
-            "text": "Controllers\n\n\nControllers help you organize related functionality into a single place. They can also be used to create RESTful resources.\n\n\nBasic\n\n\nA basic controller looks like the following:\n\n\nimport\n \nVapor\n\n\nimport\n \nHTTP\n\n\n\nfinal\n \nclass\n \nHelloController\n \n{\n\n    \nfunc\n \nsayHello\n(\n_\n \nreq\n:\n \nRequest\n)\n \nthrows\n \n-\n \nResponseRepresentable\n \n{\n\n        \nguard\n \nlet\n \nname\n \n=\n \nreq\n.\ndata\n[\nname\n]?.\nstring\n \nelse\n \n{\n \n            \nthrow\n \nAbort\n(.\nbadRequest\n)\n\n        \n}\n\n\n        \nreturn\n \nHello, \n\\(\nname\n)\n\n    \n}\n\n\n}\n\n\n\n\n\n\nSimple controllers don't need to conform to any protocols. You are free to design them however you see fit.\n\n\nRegistering\n\n\nThe only required structure is the signature of each method in the controller. In order to register this method into the router, it must have a signature like \n(Request) throws -\n ResponseRepresentable\n. \nRequest\n and \nResponseRepresentable\n are made available by importing the \nHTTP\n module.\n\n\nimport\n \nVapor\n\n\nlet\n \ndrop\n \n=\n \ntry\n \nDroplet\n()\n\n\n\nlet\n \nhc\n \n=\n \nHelloController\n()\n\n\ndrop\n.\nget\n(\nhello\n,\n \nhandler\n:\n \nhc\n.\nsayHello\n)\n\n\n\n\n\n\nSince the signature of our \nsayHello\n method matches the signature of the closure for the \ndrop.get\n method, we can pass it directly.\n\n\nType Safe\n\n\nYou can also use controller methods with type-safe routing.\n\n\nfinal\n \nclass\n \nHelloController\n \n{\n\n    \n...\n\n\n    \nfunc\n \nsayHelloAlternate\n(\n_\n \nreq\n:\n \nRequest\n)\n \n-\n \nResponseRepresentable\n \n{\n\n        \nlet\n \nname\n:\n \nString\n \n=\n \ntry\n \nreq\n.\nparameters\n.\nnext\n(\nString\n.\nself\n)\n\n        \nreturn\n \nHello, \n\\(\nname\n)\n\n    \n}\n\n\n}\n\n\n\n\n\n\nWe add a new method called \nsayHelloAlternate\n to the \nHelloController\n that fetches a \nString\n from the request's parameters.\n\n\nlet\n \nhc\n \n=\n \nHelloController\n()\n\n\ndrop\n.\nget\n(\nhello\n,\n \nString\n.\nparameter\n,\n \nhandler\n:\n \nhc\n.\nsayHelloAlternate\n)\n\n\n\n\n\n\nSince \ndrop.get\n accepts a signature \n(Request) throws -\n ResponseRepresentable\n, our method can now be used as the closure for this route. \n\n\n\n\nNote\n\n\nRead more about type safe routing in the \nRouting Parameters\n section.\n\n\n\n\nResources\n\n\nControllers that conform to \nResourceRepresentable\n can be easily registered into a router as a RESTful resource. Let's look at an example of a \nUserController\n.\n\n\nfinal\n \nclass\n \nUserController\n \n{\n\n    \nfunc\n \nindex\n(\n_\n \nreq\n:\n \nRequest\n)\n \nthrows\n \n-\n \nResponseRepresentable\n \n{\n\n        \nreturn\n \ntry\n \nUser\n.\nall\n().\nmakeJSON\n()\n\n    \n}\n\n\n    \nfunc\n \nshow\n(\n_\n \nreq\n:\n \nRequest\n)\n \nthrows\n \n-\n \nResponseRepresentable\n \n{\n\n        \nlet\n \nuser\n \n=\n \ntry\n \nreq\n.\nparameters\n.\nnext\n(\nUser\n.\nself\n)\n\n        \nreturn\n \nuser\n\n    \n}\n\n\n}\n\n\n\n\n\n\nHere is a typical user controller with an \nindex\n and \nshow\n route. Indexing returns a JSON list of all users and showing returns a JSON representation of a single user.\n\n\nWe \ncould\n register the controller like so:\n\n\nlet\n \nusers\n \n=\n \nUserController\n()\n\n\ndrop\n.\nget\n(\nusers\n,\n \nhandler\n:\n \nusers\n.\nindex\n)\n\n\ndrop\n.\nget\n(\nusers\n,\n \nUser\n.\nself\n,\n \nhandler\n:\n \nusers\n.\nshow\n)\n\n\n\n\n\n\nBut \nResourceRepresentable\n makes this standard RESTful structure easy.\n\n\nextension\n \nUserController\n:\n \nResourceRepresentable\n \n{\n\n    \nfunc\n \nmakeResource\n()\n \n-\n \nResource\nUser\n \n{\n\n        \nreturn\n \nResource\n(\n\n            \nindex\n:\n \nindex\n,\n\n            \nshow\n:\n \nshow\n\n        \n)\n\n    \n}\n\n\n}\n\n\n\n\n\n\nConforming \nUserController\n to \nResourceRepresentable\n requires that the signatures of \nthe \nindex\n and \nshow\n methods match what the \nResource\nUser\n is expecting.\n\n\nNow that \nUserController\n conforms to \nResourceRepresentable\n, registering the routes is easy.\n\n\nlet\n \nusers\n \n=\n \nUserController\n()\n\n\ndrop\n.\nresource\n(\nusers\n,\n \nusers\n)\n\n\n\n\n\n\ndrop.resource\n will take care of registering only the routes that have been supplied by the call to \nmakeResource()\n. In this case, only the \nindex\n and \nshow\n routes will be supplied.\n\n\n\n\nNote\n\n\ndrop.resource\n also adds useful defaults for OPTIONS requests. These can be overriden.  \n\n\n\n\nActions\n\n\nBelow is a table describing all of the actions available.\n\n\n\n\n\n\n\n\nAction\n\n\nMethod\n\n\nPath\n\n\nNote\n\n\n\n\n\n\n\n\n\n\nindex\n\n\nGET\n\n\n/users\n\n\nReturns all users, optionally filtered by the request data.\n\n\n\n\n\n\nstore\n\n\nPOST\n\n\n/users\n\n\nCreates a new user from the request data.\n\n\n\n\n\n\nshow\n\n\nGET\n\n\n/users/:id\n\n\nReturns the user with the ID supplied in the path.\n\n\n\n\n\n\nreplace\n\n\nPUT\n\n\n/users/:id\n\n\nUpdates the specified user, setting any fields not present in the request data to \nnil\n.\n\n\n\n\n\n\nupdate\n\n\nPATCH\n\n\n/users/:id\n\n\nUpdates the specified user, only modifying fields present in the request data.\n\n\n\n\n\n\ndelete\n\n\nDELETE\n\n\n/users/:id\n\n\nDeletes the specified user.\n\n\n\n\n\n\nclear\n\n\nDELETE\n\n\n/users\n\n\nDeletes all users, optionally filtered by the request data.\n\n\n\n\n\n\ncreate\n\n\nGET\n\n\n/users/create\n\n\nDisplays a form for creating a new user.\n\n\n\n\n\n\nedit\n\n\nGET\n\n\n/users/:id/edit\n\n\nDisplays a form for editing the specified user.\n\n\n\n\n\n\n\n\n\n\nTip\n\n\nThe difference between \nreplace\n and \nupdate\n is subtle but important:\nIf a field does not exist in the request data (for example, the user's age is missing),\n\nupdate\n should simply not update that field where as \nreplace\n should set it to \nnil\n.\nIf required data is missing from a \nreplace\n request, an error should be thrown.\n\n\n\n\nFolder\n\n\nControllers can go anywhere in your application, but they are most often stored in the \nApp/Controllers/\n directory. \n\n\n\n\nTip\n\n\nIf you are building a large application, you may want to create your controllers in a separate module. This will allow you to perform unit tests on your controllers.", 
+            "text": "Controllers\n\n\nControllers help you organize related functionality into a single place. They can also be used to create RESTful resources.\n\n\nBasic\n\n\nA basic controller looks like the following:\n\n\nimport\n \nVapor\n\n\nimport\n \nHTTP\n\n\n\nfinal\n \nclass\n \nHelloController\n \n{\n\n    \nfunc\n \nsayHello\n(\n_\n \nreq\n:\n \nRequest\n)\n \nthrows\n \n-\n \nResponseRepresentable\n \n{\n\n        \nguard\n \nlet\n \nname\n \n=\n \nreq\n.\ndata\n[\nname\n]?.\nstring\n \nelse\n \n{\n \n            \nthrow\n \nAbort\n(.\nbadRequest\n)\n\n        \n}\n\n\n        \nreturn\n \nHello, \n\\(\nname\n)\n\n    \n}\n\n\n}\n\n\n\n\n\n\nSimple controllers don't need to conform to any protocols. You are free to design them however you see fit.\n\n\nRegistering\n\n\nThe only required structure is the signature of each method in the controller. In order to register this method into the router, it must have a signature like \n(Request) throws -\n ResponseRepresentable\n. \nRequest\n and \nResponseRepresentable\n are made available by importing the \nHTTP\n module.\n\n\nimport\n \nVapor\n\n\nlet\n \ndrop\n \n=\n \ntry\n \nDroplet\n()\n\n\n\nlet\n \nhc\n \n=\n \nHelloController\n()\n\n\ndrop\n.\nget\n(\nhello\n,\n \nhandler\n:\n \nhc\n.\nsayHello\n)\n\n\n\n\n\n\nSince the signature of our \nsayHello\n method matches the signature of the closure for the \ndrop.get\n method, we can pass it directly.\n\n\nType Safe\n\n\nYou can also use controller methods with type-safe routing.\n\n\nfinal\n \nclass\n \nHelloController\n \n{\n\n    \n...\n\n\n    \nfunc\n \nsayHelloAlternate\n(\n_\n \nreq\n:\n \nRequest\n)\n \n-\n \nResponseRepresentable\n \n{\n\n        \nlet\n \nname\n:\n \nString\n \n=\n \ntry\n \nreq\n.\nparameters\n.\nnext\n(\nString\n.\nself\n)\n\n        \nreturn\n \nHello, \n\\(\nname\n)\n\n    \n}\n\n\n}\n\n\n\n\n\n\nWe add a new method called \nsayHelloAlternate\n to the \nHelloController\n that fetches a \nString\n from the request's parameters.\n\n\nlet\n \nhc\n \n=\n \nHelloController\n()\n\n\ndrop\n.\nget\n(\nhello\n,\n \nString\n.\nparameter\n,\n \nhandler\n:\n \nhc\n.\nsayHelloAlternate\n)\n\n\n\n\n\n\nSince \ndrop.get\n accepts a signature \n(Request) throws -\n ResponseRepresentable\n, our method can now be used as the closure for this route. \n\n\n\n\nNote\n\n\nRead more about type safe routing in the \nRouting Parameters\n section.\n\n\n\n\nResources\n\n\nControllers that conform to \nResourceRepresentable\n can be easily registered into a router as a RESTful resource. Let's look at an example of a \nUserController\n.\n\n\nfinal\n \nclass\n \nUserController\n \n{\n\n    \nfunc\n \nindex\n(\n_\n \nreq\n:\n \nRequest\n)\n \nthrows\n \n-\n \nResponseRepresentable\n \n{\n\n        \nreturn\n \ntry\n \nUser\n.\nall\n().\nmakeJSON\n()\n\n    \n}\n\n\n    \nfunc\n \nshow\n(\n_\n \nreq\n:\n \nRequest\n)\n \nthrows\n \n-\n \nResponseRepresentable\n \n{\n\n        \nlet\n \nuser\n \n=\n \ntry\n \nreq\n.\nparameters\n.\nnext\n(\nUser\n.\nself\n)\n\n        \nreturn\n \nuser\n\n    \n}\n\n\n}\n\n\n\n\n\n\nHere is a typical user controller with an \nindex\n and \nshow\n route. Indexing returns a JSON list of all users and showing returns a JSON representation of a single user.\n\n\nWe \ncould\n register the controller like so:\n\n\nlet\n \nusers\n \n=\n \nUserController\n()\n\n\ndrop\n.\nget\n(\nusers\n,\n \nhandler\n:\n \nusers\n.\nindex\n)\n\n\ndrop\n.\nget\n(\nusers\n,\n \nUser\n.\nself\n,\n \nhandler\n:\n \nusers\n.\nshow\n)\n\n\n\n\n\n\nBut \nResourceRepresentable\n makes this standard RESTful structure easy.\n\n\nextension\n \nUserController\n:\n \nResourceRepresentable\n \n{\n\n    \nfunc\n \nmakeResource\n()\n \n-\n \nResource\nUser\n \n{\n\n        \nreturn\n \nResource\n(\n\n            \nindex\n:\n \nindex\n,\n\n            \nshow\n:\n \nshow\n\n        \n)\n\n    \n}\n\n\n}\n\n\n\n\n\n\nConforming \nUserController\n to \nResourceRepresentable\n requires that the signatures of \nthe \nindex\n and \nshow\n methods match what the \nResource\nUser\n is expecting.\n\n\nNow that \nUserController\n conforms to \nResourceRepresentable\n, registering the routes is easy.\n\n\nlet\n \nusers\n \n=\n \nUserController\n()\n\n\ndrop\n.\nresource\n(\nusers\n,\n \nusers\n)\n\n\n\n\n\n\ndrop.resource\n will take care of registering only the routes that have been supplied by the call to \nmakeResource()\n. In this case, only the \nindex\n and \nshow\n routes will be supplied.\n\n\nActions\n\n\nBelow is a table describing all of the actions available.\n\n\n\n\n\n\n\n\nAction\n\n\nMethod\n\n\nPath\n\n\nNote\n\n\n\n\n\n\n\n\n\n\nindex\n\n\nGET\n\n\n/users\n\n\nReturns all users, optionally filtered by the request data.\n\n\n\n\n\n\nstore\n\n\nPOST\n\n\n/users\n\n\nCreates a new user from the request data.\n\n\n\n\n\n\nshow\n\n\nGET\n\n\n/users/:id\n\n\nReturns the user with the ID supplied in the path.\n\n\n\n\n\n\nreplace\n\n\nPUT\n\n\n/users/:id\n\n\nUpdates the specified user, setting any fields not present in the request data to \nnil\n.\n\n\n\n\n\n\nupdate\n\n\nPATCH\n\n\n/users/:id\n\n\nUpdates the specified user, only modifying fields present in the request data.\n\n\n\n\n\n\ndestroy\n\n\nDELETE\n\n\n/users/:id\n\n\nDeletes the specified user.\n\n\n\n\n\n\nclear\n\n\nDELETE\n\n\n/users\n\n\nDeletes all users, optionally filtered by the request data.\n\n\n\n\n\n\ncreate\n\n\nGET\n\n\n/users/create\n\n\nDisplays a form for creating a new user.\n\n\n\n\n\n\nedit\n\n\nGET\n\n\n/users/:id/edit\n\n\nDisplays a form for editing the specified user.\n\n\n\n\n\n\naboutItem\n\n\nOPTIONS\n\n\n/users/:id\n\n\nMeta action. Displays information about which actions are supported.\n\n\n\n\n\n\naboutMultiple\n\n\nOPTIONS\n\n\n/users\n\n\nMeta action. Displays information about which actions are supported.\n\n\n\n\n\n\n\n\n\n\nNote\n\n\nThe \naboutItem\n and \naboutMultiple\n meta actions are implemented automatically if not overridden. \n\n\n\n\n\n\nTip\n\n\nThe difference between \nreplace\n and \nupdate\n is subtle but important:\nIf a field does not exist in the request data (for example, the user's age is missing),\n\nupdate\n should simply not update that field where as \nreplace\n should set it to \nnil\n.\nIf required data is missing from a \nreplace\n request, an error should be thrown.\n\n\n\n\nFolder\n\n\nControllers can go anywhere in your application, but they are most often stored in the \nApp/Controllers/\n directory. \n\n\n\n\nTip\n\n\nIf you are building a large application, you may want to create your controllers in a separate module. This will allow you to perform unit tests on your controllers.", 
             "title": "Controllers"
         }, 
         {
@@ -522,12 +522,12 @@
         }, 
         {
             "location": "/vapor/controllers/#resources", 
-            "text": "Controllers that conform to  ResourceRepresentable  can be easily registered into a router as a RESTful resource. Let's look at an example of a  UserController .  final   class   UserController   { \n     func   index ( _   req :   Request )   throws   -   ResponseRepresentable   { \n         return   try   User . all (). makeJSON () \n     } \n\n     func   show ( _   req :   Request )   throws   -   ResponseRepresentable   { \n         let   user   =   try   req . parameters . next ( User . self ) \n         return   user \n     }  }   Here is a typical user controller with an  index  and  show  route. Indexing returns a JSON list of all users and showing returns a JSON representation of a single user.  We  could  register the controller like so:  let   users   =   UserController ()  drop . get ( users ,   handler :   users . index )  drop . get ( users ,   User . self ,   handler :   users . show )   But  ResourceRepresentable  makes this standard RESTful structure easy.  extension   UserController :   ResourceRepresentable   { \n     func   makeResource ()   -   Resource User   { \n         return   Resource ( \n             index :   index , \n             show :   show \n         ) \n     }  }   Conforming  UserController  to  ResourceRepresentable  requires that the signatures of \nthe  index  and  show  methods match what the  Resource User  is expecting.  Now that  UserController  conforms to  ResourceRepresentable , registering the routes is easy.  let   users   =   UserController ()  drop . resource ( users ,   users )   drop.resource  will take care of registering only the routes that have been supplied by the call to  makeResource() . In this case, only the  index  and  show  routes will be supplied.   Note  drop.resource  also adds useful defaults for OPTIONS requests. These can be overriden.", 
+            "text": "Controllers that conform to  ResourceRepresentable  can be easily registered into a router as a RESTful resource. Let's look at an example of a  UserController .  final   class   UserController   { \n     func   index ( _   req :   Request )   throws   -   ResponseRepresentable   { \n         return   try   User . all (). makeJSON () \n     } \n\n     func   show ( _   req :   Request )   throws   -   ResponseRepresentable   { \n         let   user   =   try   req . parameters . next ( User . self ) \n         return   user \n     }  }   Here is a typical user controller with an  index  and  show  route. Indexing returns a JSON list of all users and showing returns a JSON representation of a single user.  We  could  register the controller like so:  let   users   =   UserController ()  drop . get ( users ,   handler :   users . index )  drop . get ( users ,   User . self ,   handler :   users . show )   But  ResourceRepresentable  makes this standard RESTful structure easy.  extension   UserController :   ResourceRepresentable   { \n     func   makeResource ()   -   Resource User   { \n         return   Resource ( \n             index :   index , \n             show :   show \n         ) \n     }  }   Conforming  UserController  to  ResourceRepresentable  requires that the signatures of \nthe  index  and  show  methods match what the  Resource User  is expecting.  Now that  UserController  conforms to  ResourceRepresentable , registering the routes is easy.  let   users   =   UserController ()  drop . resource ( users ,   users )   drop.resource  will take care of registering only the routes that have been supplied by the call to  makeResource() . In this case, only the  index  and  show  routes will be supplied.", 
             "title": "Resources"
         }, 
         {
             "location": "/vapor/controllers/#actions", 
-            "text": "Below is a table describing all of the actions available.     Action  Method  Path  Note      index  GET  /users  Returns all users, optionally filtered by the request data.    store  POST  /users  Creates a new user from the request data.    show  GET  /users/:id  Returns the user with the ID supplied in the path.    replace  PUT  /users/:id  Updates the specified user, setting any fields not present in the request data to  nil .    update  PATCH  /users/:id  Updates the specified user, only modifying fields present in the request data.    delete  DELETE  /users/:id  Deletes the specified user.    clear  DELETE  /users  Deletes all users, optionally filtered by the request data.    create  GET  /users/create  Displays a form for creating a new user.    edit  GET  /users/:id/edit  Displays a form for editing the specified user.      Tip  The difference between  replace  and  update  is subtle but important:\nIf a field does not exist in the request data (for example, the user's age is missing), update  should simply not update that field where as  replace  should set it to  nil .\nIf required data is missing from a  replace  request, an error should be thrown.", 
+            "text": "Below is a table describing all of the actions available.     Action  Method  Path  Note      index  GET  /users  Returns all users, optionally filtered by the request data.    store  POST  /users  Creates a new user from the request data.    show  GET  /users/:id  Returns the user with the ID supplied in the path.    replace  PUT  /users/:id  Updates the specified user, setting any fields not present in the request data to  nil .    update  PATCH  /users/:id  Updates the specified user, only modifying fields present in the request data.    destroy  DELETE  /users/:id  Deletes the specified user.    clear  DELETE  /users  Deletes all users, optionally filtered by the request data.    create  GET  /users/create  Displays a form for creating a new user.    edit  GET  /users/:id/edit  Displays a form for editing the specified user.    aboutItem  OPTIONS  /users/:id  Meta action. Displays information about which actions are supported.    aboutMultiple  OPTIONS  /users  Meta action. Displays information about which actions are supported.      Note  The  aboutItem  and  aboutMultiple  meta actions are implemented automatically if not overridden.     Tip  The difference between  replace  and  update  is subtle but important:\nIf a field does not exist in the request data (for example, the user's age is missing), update  should simply not update that field where as  replace  should set it to  nil .\nIf required data is missing from a  replace  request, an error should be thrown.", 
             "title": "Actions"
         }, 
         {
diff --git a/build/2.0/vapor/controllers/index.html b/build/2.0/vapor/controllers/index.html
index be66ccf9..566b3d93 100644
--- a/build/2.0/vapor/controllers/index.html
+++ b/build/2.0/vapor/controllers/index.html
@@ -1865,10 +1865,6 @@ the <code>index</code> and <code>show</code> methods match what the <code>Resour
 
 
 <p><code>drop.resource</code> will take care of registering only the routes that have been supplied by the call to <code>makeResource()</code>. In this case, only the <code>index</code> and <code>show</code> routes will be supplied.</p>
-<div class="admonition note">
-<p class="admonition-title">Note</p>
-<p><code>drop.resource</code> also adds useful defaults for OPTIONS requests. These can be overriden.  </p>
-</div>
 <h3 id="actions">Actions<a class="headerlink" href="#actions" title="Permanent link">&para;</a></h3>
 <p>Below is a table describing all of the actions available.</p>
 <table>
@@ -1912,7 +1908,7 @@ the <code>index</code> and <code>show</code> methods match what the <code>Resour
 <td>Updates the specified user, only modifying fields present in the request data.</td>
 </tr>
 <tr>
-<td>delete</td>
+<td>destroy</td>
 <td>DELETE</td>
 <td>/users/:id</td>
 <td>Deletes the specified user.</td>
@@ -1935,8 +1931,24 @@ the <code>index</code> and <code>show</code> methods match what the <code>Resour
 <td>/users/:id/edit</td>
 <td>Displays a form for editing the specified user.</td>
 </tr>
+<tr>
+<td>aboutItem</td>
+<td>OPTIONS</td>
+<td>/users/:id</td>
+<td>Meta action. Displays information about which actions are supported.</td>
+</tr>
+<tr>
+<td>aboutMultiple</td>
+<td>OPTIONS</td>
+<td>/users</td>
+<td>Meta action. Displays information about which actions are supported.</td>
+</tr>
 </tbody>
 </table>
+<div class="admonition note">
+<p class="admonition-title">Note</p>
+<p>The <code>aboutItem</code> and <code>aboutMultiple</code> meta actions are implemented automatically if not overridden. </p>
+</div>
 <div class="admonition tip">
 <p class="admonition-title">Tip</p>
 <p>The difference between <code>replace</code> and <code>update</code> is subtle but important: