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: 
  ## Sinatra::Request
  
  You do not have to limit yourself to what you store in env. You don't have to treat it like a dumb hash, you can store any valid ruby object in it. The env can be treated like a global for sharing data between Rack apps with no real side effects.
  
  
  Sinatra's request class is a simple extension of Rack::Request. It's instantiated and any data it parses s stored in env. When you access params you are actually hitting `env['sinatra.request'].params`
  
  Sinatra::Request's main role is to parse acceptance headers.
  It parses them and then stores them on the `env` object: `env['sinatra.accept']`.
  
  Since Sinatra::Request is Rack::Request we can modify our request class to extend Sinatra::Request without any problems:
  
  ```ruby
  class Request < Sinatra::Request
  