Merge branch 'master' of git://github.com/restcookbook/restcookbook

Conflicts:
	_posts/2013-04-20-loggingin.html

_posts/2012-12-12-put-vs-post.html

@@ -9,8 +9,8 @@
 <h2 class="question">When should we use PUT and when should we use POST?</h2>
 
 <p>The HTTP methods [POST] and [PUT] aren't the HTTP equivalent of the CRUD's create and update. They both serve a
-    different purpose. It's quite possible, valid and even preferred in some occasions, to use [POST] to create resources,
-    or use [PUT] to update resources.</p>
+    different purpose. It's quite possible, valid and even preferred in some occasions, to use [PUT] to create resources,
+    or use [POST] to update resources.</p>
 
 <p>Use [PUT] when you can update a resource completely through a specific resource. For instance, if you know that an
     article resides at http://example.org/article/1234, you can [PUT] a new resource representation of this article

_posts/2012-12-13-asynchroneous-operations.html

@@ -8,7 +8,7 @@
 
 <h2 class="question">How can I let users create resources that might take a considerable amount of time. I cannot have my users wait on the API to finish.</h2>
 
-<p>Instead of creating the actual resources, create a temporary one. Instead of returning a [201] (Created) HTTP response, you can then issue at
+<p>Instead of creating the actual resources, create a temporary one. Instead of returning a [201] (Created) HTTP response, you can issue a
 [202] (Accepted) response code. This informs the client that the request has been accepted and understood by the server, but the resource is not (yet) created.
 Send the temporary resource inside the Location header.</p>
 
@@ -28,8 +28,8 @@ <h3>Response:</h3>
 
 <p>This location can store information about the status of the actual resource: an ETA on when it will be created, what is currently being done or processed.</p>
 
-<p>When the actual resource has been created, the temporary resources can return a [303] (see other) response. The location header returns the URI to the definitive
-resource. A client can either [DELETE] the temporary resource, or the server can expire this resource and return a [410] GONE later on.</p>
+<p>When the actual resource has been created, the temporary resources can return a [303] (See other) response. The location header returns the URI to the definitive
+resource. A client can either [DELETE] the temporary resource, or the server can expire this resource and return a [410] (Gone) later on.</p>
 
 
 <h3>See also</h3>

_posts/2012-12-17-json.html

@@ -8,7 +8,7 @@
 
 <h2 class="question">Is my API RESTful when I use (only) JSON?</h2>
 
-<p>Short answer: no. Long answer: no, not yet. One of the key constrains on REST is that a RESTful API must use
+<p>Short answer: no. Long answer: no, not yet. One of the key constraints on REST is that a RESTful API must use
     hypermedia formats (the HATEOAS constraint). Unfortunately, JSON is not a hypermedia format. There is no predefined
     way to deal with link discovery in JSON. One API could use the following for link discovery:</p>
 

_posts/2013-04-20-loggingin.html

@@ -29,7 +29,7 @@ <h3>HMAC</h3>
     does not safeguard against tampering of headers or body. Another way is to use HMAC (hash based message authentication).
 Instead of having passwords that need to be sent over, we actually send a hashed version of the password, together with more information.
 
-Let's assume we have the following credentials: username "johndoe", password "secret". Suppose we try to access a protected resource <b>/users/foo/financialrecords</b>.
+Let's assume we have the following credentials: username "johndoe", password "secret". Suppose we try to access a protected resource <b>/users/johndoe/financialrecords</b>.
 
 First, we need to fetch all the information we need, and concatenate this.
 
@@ -42,7 +42,7 @@ <h3>HMAC</h3>
     a hmac:</p>
 
 {% highlight xml %}
-digest = base64encode(hmac("sha256", "secret", "GET+/users/foo/financialrecords"))
+digest = base64encode(hmac("sha256", "secret", "GET+/users/johndoe/financialrecords"))
 {% endhighlight %}
 
 <p>This digest we can send over as a HTTP header:</p>
@@ -55,8 +55,8 @@ <h3>HMAC</h3>
 
 <p>
 Right now, the server knows the user "johndoe" tries to access the resource. The server can generate the digest as
-well, since it has all information (note that the "password" is not encrypted on the server, as the server needs to know
-the actual value. Hence we call this a "secret", not a "password".
+well, since it has all information. (Note that the "password" is not encrypted on the server, as the server needs to know
+the actual value. Hence we call this a "secret", not a "password").
 </p>
 
 <p>
@@ -69,7 +69,7 @@ <h3>HMAC</h3>
 </p>
 
 {% highlight xml %}
-digest = base64encode(hmac("sha256", "secret", "GET+/users/foo/financialrecords+20apr201312:59:24+123456"))
+digest = base64encode(hmac("sha256", "secret", "GET+/users/johndoe/financialrecords+20apr201312:59:24+123456"))
 {% endhighlight %}
 
 <p>We added two extra pieces of information. The current date and a number that we only use once (nonce)</p>