roy-coder
diff --git a/‎_layouts/page.html
Lines changed: 2 additions & 2 deletions b/‎_layouts/page.html
Lines changed: 2 additions & 2 deletions
diff --git a/‎about/index.md
Lines changed: 2 additions & 2 deletions b/‎about/index.md
Lines changed: 2 additions & 2 deletions
diff --git a/‎examples/index.md
Lines changed: 11 additions & 11 deletions b/‎examples/index.md
Lines changed: 11 additions & 11 deletions
diff --git a/‎extensions/index.md
Lines changed: 2 additions & 2 deletions b/‎extensions/index.md
Lines changed: 2 additions & 2 deletions
diff --git a/‎faq/index.md
Lines changed: 12 additions & 12 deletions b/‎faq/index.md
Lines changed: 12 additions & 12 deletions
@@ -20,7 +20,7 @@
     {% else %}
       {% assign page_title = page.title %}
     {% endif %}
-    <title>JSON API &mdash; {{page_title|strip }}</title>
+    <title>JSON:API &mdash; {{page_title|strip }}</title>
 
     <link href="/stylesheets/normalize.css" rel="stylesheet" type="text/css" />
     <link href="/stylesheets/all.css" rel="stylesheet" type="text/css" />
@@ -70,7 +70,7 @@
     {% if page.show_masthead %}
       <header>
         <div class="content">
-          <h1>JSON API</h1>
+          <h1>JSON:API</h1>
           <h2>A specification for building APIs in JSON</h2>
           <div class="quicklinks">
             {% for link in site.quicklinks %}
 
@@ -5,7 +5,7 @@ title: About
 
 ## <a href="#channels" id="channels" class="headerlink"></a> Channels
 
-JSON API is:
+JSON:API is:
 
   * [@jsonapi](http://twitter.com/jsonapi) on
 [Twitter](http://twitter.com)
@@ -31,7 +31,7 @@ There are five primary editors of this specification:
 
 ## <a href="#history" id="history" class="headerlink"></a> History
 
-JSON API was originally drafted by [Yehuda Katz](http://twitter.com/wycats)
+JSON:API was originally drafted by [Yehuda Katz](http://twitter.com/wycats)
 in May 2013. This first draft was extracted from the JSON transport
 implicitly defined by [Ember](http://emberjs.com/) Data's REST adapter.
 
 
@@ -25,7 +25,7 @@ Content-Type: application/vnd.api+json
     "type": "articles",
     "id": "1",
     "attributes": {
-      "title": "JSON API paints my bikeshed!",
+      "title": "JSON:API paints my bikeshed!",
       "body": "The shortest article. Ever.",
       "created": "2015-05-22T14:56:29.000Z",
       "updated": "2015-05-22T14:56:28.000Z"
@@ -71,7 +71,7 @@ Content-Type: application/vnd.api+json
     "type": "articles",
     "id": "1",
     "attributes": {
-      "title": "JSON API paints my bikeshed!",
+      "title": "JSON:API paints my bikeshed!",
       "body": "The shortest article. Ever."
     },
     "relationships": {
@@ -107,7 +107,7 @@ Content-Type: application/vnd.api+json
     "type": "articles",
     "id": "1",
     "attributes": {
-      "title": "JSON API paints my bikeshed!",
+      "title": "JSON:API paints my bikeshed!",
       "body": "The shortest article. Ever."
     }
   }],
@@ -150,7 +150,7 @@ Content-Type: application/vnd.api+json
       "type": "articles",
       "id": "3",
       "attributes": {
-        "title": "JSON API paints my bikeshed!",
+        "title": "JSON:API paints my bikeshed!",
         "body": "The shortest article. Ever.",
         "created": "2015-05-22T14:56:29.000Z",
         "updated": "2015-05-22T14:56:28.000Z"
@@ -216,7 +216,7 @@ The `status` member represents the HTTP status code associated with the problem.
 It's very helpful when multiple errors are returned at once (see below), as the
 HTTP response itself can only have one status code. However, it can also be
 useful for single errors, to save clients the trouble of consulting the HTTP
-headers, or for using JSON API over non-HTTP protocols, which may be officially
+headers, or for using JSON:API over non-HTTP protocols, which may be officially
 supported in the near future.
 
 ### <a href="#error-objects-multiple-errors" id="error-objects-multiple-errors" class="headerlink"></a> Multiple Errors
@@ -276,7 +276,7 @@ Content-Type: application/vnd.api+json
 
 > Note: in the responses above with a 422 status code, `400 Bad Request` would
 also be acceptable. ([More details.](http://stackoverflow.com/a/20215807/1261879))
-JSON API doesn't take a position on 400 vs. 422.
+JSON:API doesn't take a position on 400 vs. 422.
 
 ### <a href="#error-objects-error-codes" id="error-objects-error-codes" class="headerlink"></a> Error Codes
 
@@ -329,14 +329,14 @@ Content-Type: application/vnd.api+json
 Notice that this response includes not only the `errors` top-level member,
 but the `jsonapi` top-level member. Error responses may not contain the
 top-level `data` member, but can include all the other top-level members
-JSON API defines.
+JSON:API defines.
 
 Also, notice that the third error object lacks a `detail` member (perhaps
 for security). Again, all error object members are optional.
 
 ### <a href="#error-objects-source-usage" id="error-objects-source-usage" class="headerlink"></a> Advanced `source` Usage
 
-In the example below, the user is sending an invalid JSON API
+In the example below, the user is sending an invalid JSON:API
 request, because it's missing the `data` member:
 
 ```http
@@ -407,9 +407,9 @@ Content-Type: application/vnd.api+json
 }
 ```
 
-In most cases, JSON API requires the server to return an error when it encounters
-an invalid value for a JSON API–defined query parameter. However, for API-specific
-query parameters (i.e. those not defined by JSON API), a server may choose to
+In most cases, JSON:API requires the server to return an error when it encounters
+an invalid value for a JSON:API–defined query parameter. However, for API-specific
+query parameters (i.e. those not defined by JSON:API), a server may choose to
 ignore an invalid parameter and have the request succeed, rather than respond with
 an error. [API-specific query parameters must contain one non a-z
 character.](http://jsonapi.org/format/#query-parameters)
 
@@ -8,11 +8,11 @@ show_sidebar: true
 
 **An extension system is currently under development,** and you can view the
 latest work [here](https://github.com/json-api/json-api/tree/profile-extensions).
-There is no official support for extensions in the base JSON API specification.
+There is no official support for extensions in the base JSON:API specification.
 
 ## <a href="#prior-extensions" id="prior-extensions" class="headerlink"></a> Prior Extensions
 
-JSON API previously offered experimental support for a different extension
+JSON:API previously offered experimental support for a different extension
 negotiation system than the one now being discussed, and it provided a number of
 extensions for use with that old negotiation system. However, this system was
 always experimental and has now been deprecated.
 
@@ -4,9 +4,9 @@ title: Frequently Asked Questions
 show_sidebar: true
 ---
 
-## <a href="#what-is-the-meaning-of-json-apis-version" id="what-is-the-meaning-of-json-apis-version" class="headerlink"></a> What is the meaning of JSON API's version?
+## <a href="#what-is-the-meaning-of-json-apis-version" id="what-is-the-meaning-of-json-apis-version" class="headerlink"></a> What is the meaning of JSON:API's version?
 
-Now that JSON API has reached a stable version 1.0, it will always be
+Now that JSON:API has reached a stable version 1.0, it will always be
 backwards compatible using a _never remove, only add_ strategy.
 
 A version is maintained in order to:
@@ -18,22 +18,22 @@ A version is maintained in order to:
 
 There are several reasons:
 
-* HAL embeds child documents recursively, while JSON API flattens the entire
+* HAL embeds child documents recursively, while JSON:API flattens the entire
 graph of objects at the top level. This means that if the same "people" are
 referenced from different kinds of objects (say, the author of both posts and
 comments), this format ensures that there is only a single representation of
 each person document in the payload.
-* Similarly, JSON API uses IDs for linkage, which makes it possible to cache
+* Similarly, JSON:API uses IDs for linkage, which makes it possible to cache
 documents from compound responses and then limit subsequent requests to only
 the documents that aren't already present locally. If you're lucky, this can
 even completely eliminate HTTP requests.
 * HAL is a serialization format, but says nothing about how to update
-documents. JSON API thinks through how to update existing records (leaning on
+documents. JSON:API thinks through how to update existing records (leaning on
 PATCH and JSON Patch), and how those updates interact with compound documents
 returned from GET requests. It also describes how to create and delete
 documents, and what 200 and 204 responses from those updates mean.
 
-In short, JSON API is an attempt to formalize similar ad hoc client-server
+In short, JSON:API is an attempt to formalize similar ad hoc client-server
 interfaces that use JSON as an interchange format. It is specifically focused
 around using those APIs with a smart client that knows how to cache documents it
 has already seen and avoid asking for them again.
@@ -54,7 +54,7 @@ For instance, a client might request `HEAD /articles`, and the response could
 contain the header `Allow: GET,POST`, indicating that the client can GET the
 collection and also POST to it to create new resources.
 
-JSON API is still working on a way to for resources to advertise and detail
+JSON:API is still working on a way to for resources to advertise and detail
 non-standard actions they support. Feel free to
 [join that discussion](https://github.com/json-api/json-api/issues/745)!
 
@@ -71,15 +71,15 @@ Instead, PUT is supposed to completely replace the state of a resource:
   target resource will result in an equivalent representation being sent…”
 
 The correct method for partial updates, therefore, is [PATCH](http://tools.ietf.org/html/rfc5789),
-which is what JSON API uses. And because PATCH can also be used compliantly for
-full resource replacement, JSON API hasn't needed to define any behavior for
+which is what JSON:API uses. And because PATCH can also be used compliantly for
+full resource replacement, JSON:API hasn't needed to define any behavior for
 PUT so far. However, it may define PUT semantics in the future.
 
 In the past, many APIs used PUT for partial updates because PATCH wasn’t yet
 well-supported. However, almost all clients now support PATCH, and those that
 don’t can be easily [worked around](/recommendations/#patchless-clients).
 
-## <a href="#is-there-a-json-schema-describing-json-api" id="is-there-a-json-schema-describing-json-api" class="headerlink"></a> Is there a JSON Schema describing JSON API?
+## <a href="#is-there-a-json-schema-describing-json-api" id="is-there-a-json-schema-describing-json-api" class="headerlink"></a> Is there a JSON Schema describing JSON:API?
 
 Yes, you can find the JSON Schema definition at
 [http://jsonapi.org/schema](http://jsonapi.org/schema). This schema is as
@@ -104,6 +104,6 @@ than type because it's possible that a primary resource may have related
 resources of the same type (e.g. the "parents" of a "person"). Nesting related
 resources in `included` prevents this possible conflict.
 
-## <a href="#position-uri-structure-custom-endpoints" id="position-uri-structure-custom-endpoints" class="headerlink"></a> Does JSON API take any position on URI structure, on rules for custom endpoints, which do not fit the paradigm of GET/POST/PATCH/DELETE on the resource URI, etc.?
+## <a href="#position-uri-structure-custom-endpoints" id="position-uri-structure-custom-endpoints" class="headerlink"></a> Does JSON:API take any position on URI structure, on rules for custom endpoints, which do not fit the paradigm of GET/POST/PATCH/DELETE on the resource URI, etc.?
 
-JSON API has no requirements about URI structure, implementations are free to use whatever form they wish.
+JSON:API has no requirements about URI structure, implementations are free to use whatever form they wish.