anchor.diff:  
   <% end %>
   
  -If we only store changes on env then Rack::Request becomes easy to extend. For example, if we wanted to parse the body json and turn it into params we could do:
  +If we only store changes on env then Rack::Request becomes easy to extend. For example, if we wanted to parse the body json and turn it into params we would do:
   
   ```ruby
   class Request < Rack::Request
  
positive.code: end
  ```
  
  Request is "stateless" which means that any modifications we make to the request data are stored on the env object. This means we don't have to worry about keeping a copy of Request object around, we can create a new one from env and the new object will have all the data of the old one. Any stuff that comes after us in the call stack can either take advantage of the parsed data or ignore it without consequences -- powerful.
  
  <% note do %>
  
  
negative.code: 
  All request data from a client ends up in `env`. The server takes the data from an HTTP request, parses it and injects it into env; then env gets passed to everything. Frameworks take this raw env data, parse it, and wrap abstractions around it.
  
  Storing parsed data in env is a powerful pattern, it means we can build middleware on top of it. Frameworks often build up a level of abstraction, each bit contributing a little more detail to env. Query parsers, JSON parsers, param validators, REST helpers etc, are all built on top of and into env. And it all starts with what Rack itself provides.
  
  ## Rack::Request
  
  