README.md in restfulness-0.3.3 vs README.md in restfulness-0.3.4

@@ -412,18 +412,43 @@
 
 ```ruby
 Restfulness.sensitive_params = [:password, :secretkey]
 ```
 
-## Error Handling
+## Status Code and Error Handling
 
-If you'd like your application to return anything other than a 200 (or 202) status, you have a couple of options that allow you to send codes back to the client.
+If you'd like your application to return anything other than a 200 status (or 204 for an empty payload), you can set it directly on the response object:
 
-One of the easiest approaches is to update the `response` code. Take the following example where we set a 403 response and the model's errors object in the payload:
+```ruby
+class ProjectResource < Restfulness::Resource
+  def get
+    response.status = 203
+    project
+  end
+end
+```
 
+The recommended approach in Restfulness however is to use the success status code helpers, for example:
+
 ```ruby
 class ProjectResource < Restfulness::Resource
+  def get
+    non_authoritative(project) # Respond with 203
+  end
+  def put
+    build_project
+    created(project) # Respond with 201
+  end
+end
+```
+
+Any payload passed into the helper will be returned after setting the code.
+
+Dealing with error responses (3XX, or 4XX codes) can also be dealt with using the `response` object. Take the following example where we set a 403 response and the model's errors object in the payload:
+
+```ruby
+class ProjectResource < Restfulness::Resource
   def patch
     if project.update_attributes(request.params)
       project
     else
       response.status = 403
@@ -431,11 +456,11 @@
     end
   end
 end
 ```
 
-The favourite method in Restfulness however is to use the `HTTPException` class and helper methods that will raise the error for you. For example:
+Continuing from the recommended approach for success helpers, Restfulness provides a `HTTPException` class and "bang" helper methods that will raise the error for you. For example:
 
 ```ruby
 class ProjectResource < Restfulness::Resource
   def patch
     unless project.update_attributes(request.params)
@@ -444,11 +469,11 @@
     project
   end
 end
 ```
 
-The `forbidden!` bang method will call the `error!` method, which in turn will raise an `HTTPException` with the appropriate status code. Exceptions are permitted to include a payload also, so you could override the `error!` method if you wished with code that will automatically re-format the payload. Another example:
+The `forbidden!` bang method will call the `error!` method, which in turn will raise an `HTTPException` containing the appropriate status code. Exceptions are permitted to include a payload also, so you can override the `error!` method if you wished with code that will automatically re-format the payload. Another example:
 
 ```ruby
 # Regular resource
 class ProjectResource < ApplicationResource
   def patch
@@ -476,12 +501,22 @@
 
 ```
 
 This can be a really nice way to mold your errors into a standard format. All HTTP exceptions generated inside resources will pass through `error!`, even those that a triggered by a callback. It gives a great way to provide your own JSON error payload, or even just resort to a simple string.
 
-The currently built in exception methods are:
+The current built in success methods are:
 
+ * `ok` - code 200, the default.
+ * `created` - code 201.
+ * `accepted` - code 202.
+ * `non_authoritative_information` - code 203.
+ * `non_authoritative` - code 203, same as previous, but a shorter method name.
+ * `no_content` - code 204, default when no payload provided.
+ * `reset_content` - code 205.
+
+The current built in exception methods are:
+
  * `not_modified!`
  * `bad_request!`
  * `unauthorized!`
  * `payment_required!`
  * `forbidden!`
@@ -668,9 +703,14 @@
  * Support redirect exceptions.
  * Needs more functional testing.
  * Support for before and after filters in resources, although I'm slightly apprehensive about this.
 
 ## History
+
+### 0.3.4 - August 8, 2016
+
+ * Added helper methods for success responses (@samlown)
+ * Don't initialize AuthorizationHeader when authorization is blank. (@arctarus)
 
 ### 0.3.3 - January 19, 2016
 
  * Basic support for handling large request bodies received as Tempfile (@lauramorillo)
  * Providing human readable payload for invalid JSON.