Docs: Fix order for PUT _mapping docs

Closes #8083

docs/reference/indices/put-mapping.asciidoc

@@ -6,7 +6,7 @@ specific type.
 
 [source,js]
 --------------------------------------------------
-$ curl -XPUT 'http://localhost:9200/twitter/tweet/_mapping' -d '
+$ curl -XPUT 'http://localhost:9200/twitter/_mapping/tweet' -d '
 {
     "tweet" : {
         "properties" : {
@@ -49,7 +49,7 @@ call, or even on `_all` the indices.
 
 [source,js]
 --------------------------------------------------
-$ curl -XPUT 'http://localhost:9200/kimchy,elasticsearch/tweet/_mapping' -d '
+$ curl -XPUT 'http://localhost:9200/kimchy,elasticsearch/_mapping/tweet' -d '
 {
     "tweet" : {
         "properties" : {
@@ -65,19 +65,18 @@ All options:
 [source,js]
 --------------------------------------------------
 
-PUT /{index}/_mapping/{type}        
+PUT /{index}/_mapping/{type}
-         
+
 
 --------------------------------------------------
-    
+
 
 where
 
 [horizontal]
 `{index}`:: `blank | * | _all | glob pattern | name1, name2, …`
-    
+
 `{type}`:: Name of the type to add. Must be the name of the type defined in the body.
 
 
 Instead of `_mapping` you can also use the plural `_mappings`.
-The uri `PUT /{index}/{type}/_mapping` is still supported for backwards compatibility.  

docs/reference/mapping/dynamic-mapping.asciidoc

@@ -39,7 +39,7 @@ disables dynamic field creation for a `tweet`:
 
 [source,js]
 --------------------------------------------------
-$ curl -XPUT 'http://localhost:9200/twitter/tweet/_mapping' -d '
+$ curl -XPUT 'http://localhost:9200/twitter/_mapping/tweet' -d '
 {
     "tweet" : {
         "dynamic": "strict",
@@ -76,4 +76,3 @@ chance that the wrong field type will be used.
 This requirement can be disabled by setting
 `index.query.parse.allow_unmapped_fields` to `true`, in which case you run the
 risk that your query or filter might not work correctly.
-

docs/reference/search/suggesters/context-suggest.asciidoc

@@ -6,7 +6,7 @@ suggester system provides a very fast way of searching documents by handling the
 entirely in memory. But this special treatment does not allow the handling of
 traditional queries and filters, because those would have notable impact on the
 performance. So the context extension is designed to take so-called context information
-into account to specify a more accurate way of searching within the suggester system. 
+into account to specify a more accurate way of searching within the suggester system.
 Instead of using the traditional query and filter system a predefined ``context`` is
 configured to limit suggestions to a particular subset of suggestions.
 Such a context is defined by a set of context mappings which can either be a simple
@@ -17,7 +17,7 @@ For instance:
 
 [source,js]
 --------------------------------------------------
-PUT services/service/_mapping
+PUT services/_mapping/service
 {
     "service": {
         "properties": {
@@ -315,4 +315,3 @@ POST services/_suggest
     }
 }
 --------------------------------------------------
-