<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>[2338] 2013/rmccue/trunk/docs: Move the documentation into a nicer layout</title>
</head>
<body>
<style type="text/css"><!--
#msg dl.meta { border: 1px #006 solid; background: #369; padding: 6px; color: #fff; }
#msg dl.meta dt { float: left; width: 6em; font-weight: bold; }
#msg dt:after { content:':';}
#msg dl, #msg dt, #msg ul, #msg li, #header, #footer, #logmsg { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; }
#msg dl a { font-weight: bold}
#msg dl a:link { color:#fc3; }
#msg dl a:active { color:#ff0; }
#msg dl a:visited { color:#cc6; }
h3 { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; font-weight: bold; }
#msg pre { overflow: auto; background: #ffc; border: 1px #fa0 solid; padding: 6px; }
#logmsg { background: #ffc; border: 1px #fa0 solid; padding: 1em 1em 0 1em; }
#logmsg p, #logmsg pre, #logmsg blockquote { margin: 0 0 1em 0; }
#logmsg p, #logmsg li, #logmsg dt, #logmsg dd { line-height: 14pt; }
#logmsg h1, #logmsg h2, #logmsg h3, #logmsg h4, #logmsg h5, #logmsg h6 { margin: .5em 0; }
#logmsg h1:first-child, #logmsg h2:first-child, #logmsg h3:first-child, #logmsg h4:first-child, #logmsg h5:first-child, #logmsg h6:first-child { margin-top: 0; }
#logmsg ul, #logmsg ol { padding: 0; list-style-position: inside; margin: 0 0 0 1em; }
#logmsg ul { text-indent: -1em; padding-left: 1em; }#logmsg ol { text-indent: -1.5em; padding-left: 1.5em; }
#logmsg > ul, #logmsg > ol { margin: 0 0 1em 0; }
#logmsg pre { background: #eee; padding: 1em; }
#logmsg blockquote { border: 1px solid #fa0; border-left-width: 10px; padding: 1em 1em 0 1em; background: white;}
#logmsg dl { margin: 0; }
#logmsg dt { font-weight: bold; }
#logmsg dd { margin: 0; padding: 0 0 0.5em 0; }
#logmsg dd:before { content:'\00bb';}
#logmsg table { border-spacing: 0px; border-collapse: collapse; border-top: 4px solid #fa0; border-bottom: 1px solid #fa0; background: #fff; }
#logmsg table th { text-align: left; font-weight: normal; padding: 0.2em 0.5em; border-top: 1px dotted #fa0; }
#logmsg table td { text-align: right; border-top: 1px dotted #fa0; padding: 0.2em 0.5em; }
#logmsg table thead th { text-align: center; border-bottom: 1px solid #fa0; }
#logmsg table th.Corner { text-align: left; }
#logmsg hr { border: none 0; border-top: 2px dashed #fa0; height: 1px; }
#header, #footer { color: #fff; background: #636; border: 1px #300 solid; padding: 6px; }
#patch { width: 100%; }
#patch h4 {font-family: verdana,arial,helvetica,sans-serif;font-size:10pt;padding:8px;background:#369;color:#fff;margin:0;}
#patch .propset h4, #patch .binary h4 {margin:0;}
#patch pre {padding:0;line-height:1.2em;margin:0;}
#patch .diff {width:100%;background:#eee;padding: 0 0 10px 0;overflow:auto;}
#patch .propset .diff, #patch .binary .diff {padding:10px 0;}
#patch span {display:block;padding:0 10px;}
#patch .modfile, #patch .addfile, #patch .delfile, #patch .propset, #patch .binary, #patch .copfile {border:1px solid #ccc;margin:10px 0;}
#patch ins {background:#dfd;text-decoration:none;display:block;padding:0 10px;}
#patch del {background:#fdd;text-decoration:none;display:block;padding:0 10px;}
#patch .lines, .info {color:#888;background:#fff;}
--></style>
<div id="msg">
<dl class="meta">
<dt>Revision</dt> <dd><a href="http://gsoc.trac.wordpress.org/changeset/2338">2338</a></dd>
<dt>Author</dt> <dd>rmccue</dd>
<dt>Date</dt> <dd>2013-09-21 09:04:38 +0000 (Sat, 21 Sep 2013)</dd>
</dl>
<h3>Log Message</h3>
<pre>Move the documentation into a nicer layout</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#2013rmccuetrunkdocsguidesextendingmd">2013/rmccue/trunk/docs/guides/extending.md</a></li>
<li><a href="#2013rmccuetrunkdocsguidesgettingstartedmd">2013/rmccue/trunk/docs/guides/getting-started.md</a></li>
<li><a href="#2013rmccuetrunkdocsguidesworkingwithpostsmd">2013/rmccue/trunk/docs/guides/working-with-posts.md</a></li>
</ul>
<h3>Added Paths</h3>
<ul>
<li><a href="#2013rmccuetrunkdocscompatibilitymd">2013/rmccue/trunk/docs/compatibility.md</a></li>
<li>2013/rmccue/trunk/docs/internals/</li>
<li><a href="#2013rmccuetrunkdocsinternalsimplementationmd">2013/rmccue/trunk/docs/internals/implementation.md</a></li>
<li><a href="#2013rmccuetrunkdocsinternalsphilosophymd">2013/rmccue/trunk/docs/internals/philosophy.md</a></li>
<li>2013/rmccue/trunk/docs/routes/</li>
<li><a href="#2013rmccuetrunkdocsroutesmediamd">2013/rmccue/trunk/docs/routes/media.md</a></li>
<li><a href="#2013rmccuetrunkdocsroutespostsmd">2013/rmccue/trunk/docs/routes/posts.md</a></li>
<li><a href="#2013rmccuetrunkdocsschemamd">2013/rmccue/trunk/docs/schema.md</a></li>
</ul>
<h3>Removed Paths</h3>
<ul>
<li><a href="#2013rmccuetrunkdocsimplementationmd">2013/rmccue/trunk/docs/implementation.md</a></li>
<li><a href="#2013rmccuetrunkdocsphilosophymd">2013/rmccue/trunk/docs/philosophy.md</a></li>
<li><a href="#2013rmccuetrunkdocsroutesmediamd">2013/rmccue/trunk/docs/routes-media.md</a></li>
<li><a href="#2013rmccuetrunkdocsroutespostsmd">2013/rmccue/trunk/docs/routes-posts.md</a></li>
<li><a href="#2013rmccuetrunkdocsroutesmd">2013/rmccue/trunk/docs/routes.md</a></li>
<li><a href="#2013rmccuetrunkdocswpjsonmd">2013/rmccue/trunk/docs/wp-json.md</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="2013rmccuetrunkdocscompatibilitymdfromrev23372013rmccuetrunkdocsroutesmd"></a>
<div class="copfile"><h4>Copied: 2013/rmccue/trunk/docs/compatibility.md (from rev 2337, 2013/rmccue/trunk/docs/routes.md) (0 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/compatibility.md (rev 0)
+++ 2013/rmccue/trunk/docs/compatibility.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -0,0 +1,41 @@
</span><ins>+Notes
+=====
+
+### Inputting data as an "array"
+Endpoints may allow passing in an array of data, typically used for querying
+entities. URL semantics do not specify how to pass this, however the convention
+used by PHP and this API is to pass them with the array name concatenated with
+the key name in square brackets.
+
+For example:
+
+ filter[post_status]=draft&filter[s]=foo
+
+
+### JSON data input
+Some posts allow directly passing JSON data (usually an entity) via the request
+body. These should be specified with a Content-Type header of `application/json`
+although individual endpoints may prefer more specific types.
+
+If your client platform does not support native JSON encoding, the data can be
+submitted via a regular HTTP multipart body, with properties set as values to
+the `data` parameter.
+
+That is, the following are equivalent:
+
+Content-Type: application/x-www-form-urlencoded
+
+ data[post_title]=Hello%20World!&data[post_content]=Content
+
+
+Content-Type: application/json
+
+ {"post_title":"Hello World!","post_content":"Content"}
+
+
+### HTTP method compatibility
+Due to their relatively new nature, some methods such as PATCH may not be
+supported by client software. To emulate support for this, a `_method` parameter
+may be passed via the URL with the value set to a valid HTTP method (DELETE,
+GET, HEAD, PATCH, POST, PUT, DELETE). Note that this must be passed via the URL
+and cannot be passed in the HTTP body.
</ins></span></pre></div>
<a id="2013rmccuetrunkdocsguidesextendingmd"></a>
<div class="modfile"><h4>Modified: 2013/rmccue/trunk/docs/guides/extending.md (2337 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/guides/extending.md 2013-09-21 09:04:26 UTC (rev 2337)
+++ 2013/rmccue/trunk/docs/guides/extending.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -304,6 +304,6 @@
</span><span class="cx"> own entity design.
</span><span class="cx"> * [Internal Implementation][]: Learn about how the REST server works internally.
</span><span class="cx">
</span><del>-[API Philosophy]: ../philosophy.md
-[Schema]: ../wp-json.md
-[Internal Implementation]: ../implementation.md
</del><ins>+[API Philosophy]: ../internals/philosophy.md
+[Schema]: ../schema.md
+[Internal Implementation]: ../internals/implementation.md
</ins></span></pre></div>
<a id="2013rmccuetrunkdocsguidesgettingstartedmd"></a>
<div class="modfile"><h4>Modified: 2013/rmccue/trunk/docs/guides/getting-started.md (2337 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/guides/getting-started.md 2013-09-21 09:04:26 UTC (rev 2337)
+++ 2013/rmccue/trunk/docs/guides/getting-started.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -430,4 +430,4 @@
</span><span class="cx"> * [Schema][schema]: View technical information on all the available data
</span><span class="cx">
</span><span class="cx"> [Working with Posts]: working-with-posts.md
</span><del>-[schema]: ../wp-json.md
</del><ins>+[schema]: ../schema.md
</ins></span></pre></div>
<a id="2013rmccuetrunkdocsguidesworkingwithpostsmd"></a>
<div class="modfile"><h4>Modified: 2013/rmccue/trunk/docs/guides/working-with-posts.md (2337 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/guides/working-with-posts.md 2013-09-21 09:04:26 UTC (rev 2337)
+++ 2013/rmccue/trunk/docs/guides/working-with-posts.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -277,7 +277,9 @@
</span><span class="cx"> take a look at the other APIs, or look at documentation on the specifics.
</span><span class="cx">
</span><span class="cx"> * [Schema][schema]: Full documentation of every parameter for the APIs.
</span><ins>+* [Extending the API][]: Create your own API endpoints.
</ins><span class="cx">
</span><span class="cx"> [Getting Started]: getting-started.md
</span><del>-[schema]: ../wp-json.md
</del><ins>+[Extending the API]: extending.md
+[schema]: ../schema.md
</ins><span class="cx"> [WP_Query]: http://codex.wordpress.org/Class_Reference/WP_Query
</span></span></pre></div>
<a id="2013rmccuetrunkdocsimplementationmd"></a>
<div class="delfile"><h4>Deleted: 2013/rmccue/trunk/docs/implementation.md (2337 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/implementation.md 2013-09-21 09:04:26 UTC (rev 2337)
+++ 2013/rmccue/trunk/docs/implementation.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -1,52 +0,0 @@
</span><del>-Implementation Details
-======================
-
-Method Naming
--------------
-By convention, routing code uses underscore_case for method naming, whereas
-endpoints use partialCamelCase.
-
-
-Routing
--------
-The routing code is written in such a way to ensure that the input and output
-are handled only by this code.
-
-The majority of state is handled in the `serve_request()` method, which handles
-both reading input and serializing the output to JSON. This is responsible for
-translating HTTP to an internal representation suitable for dispatching.
-
-The routing code also operates with global state, as it's intended to handle the
-HTTP interactions, which is inherently global in PHP.
-
-The `dispatch()` method handles matching the requested route with an endpoint.
-This method also deals with global state for GET and POST parameters, however
-this is not the optimal situation, as it requires reimplementation of the
-routing code when embedding the API.
-
-This could possibly be optimized by performing straight string matching for the
-static portion of the URL. Symfony uses this internally in their routing,
-although they don't allow arbitrary regular expressions for routes.
-
-
-Parameters
-----------
-Endpoints take parameters as direct function arguments. This fits in with the
-philosophy that the endpoints should match up with functions fairly directly.
-This means that in order to write an endpoint, all you need to know is how to
-write a function.
-
-This uses the Reflection API to match provided parameters up with the function's
-parameters in the correct order, and with default values as needed. The
-performance of this API is anecdotally not a real consideration, however
-benchmarks are yet to be taken in a rigorous manner.
-
-Intentionally, it is not possible to get all supplied parameters. This is
-regarded as a bad API smell, as each parameter should be fully documented for
-consumers. It is possible to construct hacks around this using the
-`json_dispatch_args` filter, but this is intentionally made to feel hacky.
-
-Some parameters which give information about the context of the call. These are
-prefixed with an underscore, and are *always* set. This ensures that a rogue
-consumer can't pass in the internal name to override it and possibly cause a
-security issue.
</del></span></pre></div>
<a id="2013rmccuetrunkdocsinternalsimplementationmdfromrev23372013rmccuetrunkdocsimplementationmd"></a>
<div class="copfile"><h4>Copied: 2013/rmccue/trunk/docs/internals/implementation.md (from rev 2337, 2013/rmccue/trunk/docs/implementation.md) (0 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/internals/implementation.md (rev 0)
+++ 2013/rmccue/trunk/docs/internals/implementation.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -0,0 +1,52 @@
</span><ins>+Implementation Details
+======================
+
+Method Naming
+-------------
+By convention, routing code uses underscore_case for method naming, whereas
+endpoints use partialCamelCase.
+
+
+Routing
+-------
+The routing code is written in such a way to ensure that the input and output
+are handled only by this code.
+
+The majority of state is handled in the `serve_request()` method, which handles
+both reading input and serializing the output to JSON. This is responsible for
+translating HTTP to an internal representation suitable for dispatching.
+
+The routing code also operates with global state, as it's intended to handle the
+HTTP interactions, which is inherently global in PHP.
+
+The `dispatch()` method handles matching the requested route with an endpoint.
+This method also deals with global state for GET and POST parameters, however
+this is not the optimal situation, as it requires reimplementation of the
+routing code when embedding the API.
+
+This could possibly be optimized by performing straight string matching for the
+static portion of the URL. Symfony uses this internally in their routing,
+although they don't allow arbitrary regular expressions for routes.
+
+
+Parameters
+----------
+Endpoints take parameters as direct function arguments. This fits in with the
+philosophy that the endpoints should match up with functions fairly directly.
+This means that in order to write an endpoint, all you need to know is how to
+write a function.
+
+This uses the Reflection API to match provided parameters up with the function's
+parameters in the correct order, and with default values as needed. The
+performance of this API is anecdotally not a real consideration, however
+benchmarks are yet to be taken in a rigorous manner.
+
+Intentionally, it is not possible to get all supplied parameters. This is
+regarded as a bad API smell, as each parameter should be fully documented for
+consumers. It is possible to construct hacks around this using the
+`json_dispatch_args` filter, but this is intentionally made to feel hacky.
+
+Some parameters which give information about the context of the call. These are
+prefixed with an underscore, and are *always* set. This ensures that a rogue
+consumer can't pass in the internal name to override it and possibly cause a
+security issue.
</ins></span></pre></div>
<a id="2013rmccuetrunkdocsinternalsphilosophymdfromrev23372013rmccuetrunkdocsphilosophymd"></a>
<div class="copfile"><h4>Copied: 2013/rmccue/trunk/docs/internals/philosophy.md (from rev 2337, 2013/rmccue/trunk/docs/philosophy.md) (0 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/internals/philosophy.md (rev 0)
+++ 2013/rmccue/trunk/docs/internals/philosophy.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -0,0 +1,72 @@
</span><ins>+Philosophy
+==========
+
+Rules
+-----
+
+### Rule 1: Avoid writing global state
+
+ For example, the routing code is responsible for handling all input and output,
+ so direct calls from methods to functions such as `header()` or `echo` should
+ be avoided completely.
+
+### Rule 2: Endpoints must be embeddable
+
+ Endpoints should be able to call each other without worrying about global state.
+ This follows from Rule 1, in that global state must be avoided for this, however
+ this also means that endpoints can be expected to be called internally.
+
+### Rule 3: Explict is better than implicit
+
+ You should never have to guess where a variable came from, or why a method was
+ called. Routes should have a 1:1 mapping with endpoints and magic catch-all
+ routes should be avoided. Parameters should always be documented as if the API
+ was a closed (source) box.
+
+### Rule 4: Reduce, reuse, recycle
+
+ Reduce the complexity of clients and the server.
+
+ Reuse code where possible.
+
+ Recycle endpoints by building on the existing instead of reinventing.
+
+
+Guidelines
+----------
+
+### Guideline 1: Endpoints should operate like regular functions
+
+ By using the API, you're essentially using a form of Remote Procedure Call.
+ Both remote and local calls should look essentially the same while operating
+ within the convention of REST calls for the remote calls.
+
+ Parameters to endpoints follow this rule, wherein remote parameters are
+ matched up with defined parameters in the endpoint. More detailed structures
+ are handled as entities, which have a clearly defined structure in
+ the specification.
+
+ This follows from Rules 2 and 3.
+
+### Guideline 2: Endpoints should avoid assuming HTTP/JSON characteristics
+
+ Although the API usually operates over HTTP using JSON, endpoints can safely
+ assume that the serialization may take place using a different serializer
+ (such as protobufs or bson) over a different transport (such as ZeroMQ).
+
+ This doesn't mean that endpoints need to reinvent the wheel; HTTP status codes
+ and header names are used since this is the normal state. However, values
+ should never be encoded in endpoints for HTTP transport rules or JSON encoding
+ rules.
+
+ This follows from Rules 1 and 2.
+
+### Guideline 3: Base responses around entities
+
+ Being explicit with data formats means documenting everything. No one likes
+ writing documentation constantly, so these data formats should be based around
+ the concept of reusable entities.
+
+ This simplifies the code and reduces the workload of documentation.
+
+ This follows from Rules 3 and 4.
</ins></span></pre></div>
<a id="2013rmccuetrunkdocsphilosophymd"></a>
<div class="delfile"><h4>Deleted: 2013/rmccue/trunk/docs/philosophy.md (2337 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/philosophy.md 2013-09-21 09:04:26 UTC (rev 2337)
+++ 2013/rmccue/trunk/docs/philosophy.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -1,72 +0,0 @@
</span><del>-Philosophy
-==========
-
-Rules
------
-
-### Rule 1: Avoid writing global state
-
- For example, the routing code is responsible for handling all input and output,
- so direct calls from methods to functions such as `header()` or `echo` should
- be avoided completely.
-
-### Rule 2: Endpoints must be embeddable
-
- Endpoints should be able to call each other without worrying about global state.
- This follows from Rule 1, in that global state must be avoided for this, however
- this also means that endpoints can be expected to be called internally.
-
-### Rule 3: Explict is better than implicit
-
- You should never have to guess where a variable came from, or why a method was
- called. Routes should have a 1:1 mapping with endpoints and magic catch-all
- routes should be avoided. Parameters should always be documented as if the API
- was a closed (source) box.
-
-### Rule 4: Reduce, reuse, recycle
-
- Reduce the complexity of clients and the server.
-
- Reuse code where possible.
-
- Recycle endpoints by building on the existing instead of reinventing.
-
-
-Guidelines
-----------
-
-### Guideline 1: Endpoints should operate like regular functions
-
- By using the API, you're essentially using a form of Remote Procedure Call.
- Both remote and local calls should look essentially the same while operating
- within the convention of REST calls for the remote calls.
-
- Parameters to endpoints follow this rule, wherein remote parameters are
- matched up with defined parameters in the endpoint. More detailed structures
- are handled as entities, which have a clearly defined structure in
- the specification.
-
- This follows from Rules 2 and 3.
-
-### Guideline 2: Endpoints should avoid assuming HTTP/JSON characteristics
-
- Although the API usually operates over HTTP using JSON, endpoints can safely
- assume that the serialization may take place using a different serializer
- (such as protobufs or bson) over a different transport (such as ZeroMQ).
-
- This doesn't mean that endpoints need to reinvent the wheel; HTTP status codes
- and header names are used since this is the normal state. However, values
- should never be encoded in endpoints for HTTP transport rules or JSON encoding
- rules.
-
- This follows from Rules 1 and 2.
-
-### Guideline 3: Base responses around entities
-
- Being explicit with data formats means documenting everything. No one likes
- writing documentation constantly, so these data formats should be based around
- the concept of reusable entities.
-
- This simplifies the code and reduces the workload of documentation.
-
- This follows from Rules 3 and 4.
</del></span></pre></div>
<a id="2013rmccuetrunkdocsroutesmediamdfromrev23372013rmccuetrunkdocsroutesmediamd"></a>
<div class="copfile"><h4>Copied: 2013/rmccue/trunk/docs/routes/media.md (from rev 2337, 2013/rmccue/trunk/docs/routes-media.md) (0 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/routes/media.md (rev 0)
+++ 2013/rmccue/trunk/docs/routes/media.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -0,0 +1,52 @@
</span><ins>+Media
+=====
+
+Get Attachments
+---------------
+The Attachments endpoint returns an Attachment collection containing a subset of
+the site's attachments.
+
+This endpoint is an extended version of the Post retrieval endpoint.
+
+ GET /media
+
+### Input
+#### `fields`
+...
+
+### Response
+The response is an Attachment entity containing the requested Attachment if
+available.
+
+
+Create an Attachment
+--------------------
+The Create Attachment endpoint is used to create the raw data for an attachment.
+This is a binary object (blob), such as image data or a video.
+
+ POST /media
+
+### Input
+The attachment creation endpoint can accept data in two forms.
+
+The primary input method accepts raw data POSTed with the corresponding content
+type set via the `Content-Type` HTTP header. This is the preferred submission
+method.
+
+The secondary input method accepts data POSTed via `multipart/form-data`, as per
+[RFC 2388][]. The uploaded file should be submitted with the name field set to
+"file", and the filename field set to the relevant filename for the file.
+
+In addition, a `Content-MD5` header can be set with the MD5 hash of the file, to
+enable the server to check for consistency errors. If the supplied hash does not
+match the hash calculated on the server, a 412 Precondition Failed header will
+be issued.
+
+[RFC 2388]: http://tools.ietf.org/html/rfc2388
+
+### Response
+On a successful creation, a 201 Created status is given, indicating that the
+attachment has been created. The attachment is available canonically from the
+URL specified in the Location header.
+
+The new Attachment entity is also returned in the body for convienience.
</ins><span class="cx">\ No newline at end of file
</span></span></pre></div>
<a id="2013rmccuetrunkdocsroutespostsmdfromrev23372013rmccuetrunkdocsroutespostsmd"></a>
<div class="copfile"><h4>Copied: 2013/rmccue/trunk/docs/routes/posts.md (from rev 2337, 2013/rmccue/trunk/docs/routes-posts.md) (0 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/routes/posts.md (rev 0)
+++ 2013/rmccue/trunk/docs/routes/posts.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -0,0 +1,126 @@
</span><ins>+Posts
+=====
+
+Retrieve Posts
+--------------
+The Posts endpoint returns a Post Collection containing a subset of the site's
+posts.
+
+ GET /posts
+
+### Input
+#### `filter`
+The `filter` parameter controls the query parameters. It is essentially a subset
+of the parameters available to [`WP_Query`](http://codex.wordpress.org/Class_Reference/WP_Query).
+
+The parameter should be an array of the following key/value pairs:
+
+* `post_status` - Comma-separated list of [status
+ values](http://codex.wordpress.org/Class_Reference/WP_Query#Status_Parameters).
+ Default is "publish". (string)
+* `numberposts` - Number of posts to retrieve, use `-1` for all posts. Default
+ is set by the site. (integer)
+* `offset` - Number of posts to skip. Default is 0. (integer)
+* `orderby` - Parameter to search by, as per [WP Query](http://codex.wordpress.org/Class_Reference/WP_Query#Order_.26_Orderby_Parameters).
+ Default is "date". (string)
+* `order` - Order to sort by. Default is "DESC". (string, "ASC" or "DESC")
+* `s` - Keyword to search for. (string)
+
+
+#### `fields`
+...
+
+
+#### `type`
+The `type` parameter specifies the post type to retrieve. Default is "post".
+(string)
+
+
+### Response
+The response is a Post Collection document containing the requested Posts if
+available.
+
+
+Create a Post
+-------------
+
+ POST /posts
+
+### Input
+The supplied data should be a Post object. This data can be submitted via a
+regular HTTP multipart body, with Post values set as values to the `data`
+parameter, or through a direct JSON body.
+
+That is, the following are equivalent:
+
+Content-Type: application/x-www-form-urlencoded
+
+ data[post_title]=Hello%20World!&data[post_content]=Content
+
+
+Content-Type: application/json
+
+ {"post_title":"Hello World!","post_content":"Content"}
+
+### Response
+On a successful creation, a 201 Created status is given, indicating that the
+post has been created. The post is available canonically from the URL specified
+in the Location header.
+
+The new Post entity is also returned in the body for convienience.
+
+
+Retrieve a Post
+---------------
+
+ GET /posts/<id>
+
+### Input
+#### `fields`
+...
+
+### Response
+The response is a Post entity containing the requested Post if available.
+
+
+Edit a Post
+-----------
+
+ PUT /posts/<id>
+
+For compatibility reasons, this endpoint also accepts the POST and PATCH
+methods. Both of these methods have the same behaviour as using PUT. It is
+recommended to use PUT if available to fit with REST convention.
+
+### Input
+The supplied data should be a Post object. This data can be submitted via a
+regular HTTP multipart body, with Post values set as values to the `data`
+parameter, or through a direct JSON body. See the Create Post endpoint for an
+example.
+
+### Response
+On a successful update, a 200 OK status is given, indicating the post has been
+updated. The updated Post entity is returned in the body.
+
+
+Delete a Post
+-------------
+
+ DELETE /posts/<id>
+
+### Input
+#### `force`
+The `force` parameter controls whether the post is permanently deleted or not.
+By default, this is set to false, indicating that the post will be sent to an
+intermediate storage (such as the trash) allowing it to be restored later. If
+set to true, the post will not be able to be restored by the user.
+
+Default is false. (boolean)
+
+### Response
+On successful deletion, a 202 Accepted status code will be returned, indicating
+that the post has been moved to the trash for permanent deletion at a
+later date.
+
+If force was set to true, a 200 OK status code will be returned instead,
+indicating that the post has been permanently deleted.
</ins><span class="cx">\ No newline at end of file
</span></span></pre></div>
<a id="2013rmccuetrunkdocsroutesmediamd"></a>
<div class="delfile"><h4>Deleted: 2013/rmccue/trunk/docs/routes-media.md (2337 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/routes-media.md 2013-09-21 09:04:26 UTC (rev 2337)
+++ 2013/rmccue/trunk/docs/routes-media.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -1,52 +0,0 @@
</span><del>-Media
-=====
-
-Get Attachments
----------------
-The Attachments endpoint returns an Attachment collection containing a subset of
-the site's attachments.
-
-This endpoint is an extended version of the Post retrieval endpoint.
-
- GET /media
-
-### Input
-#### `fields`
-...
-
-### Response
-The response is an Attachment entity containing the requested Attachment if
-available.
-
-
-Create an Attachment
---------------------
-The Create Attachment endpoint is used to create the raw data for an attachment.
-This is a binary object (blob), such as image data or a video.
-
- POST /media
-
-### Input
-The attachment creation endpoint can accept data in two forms.
-
-The primary input method accepts raw data POSTed with the corresponding content
-type set via the `Content-Type` HTTP header. This is the preferred submission
-method.
-
-The secondary input method accepts data POSTed via `multipart/form-data`, as per
-[RFC 2388][]. The uploaded file should be submitted with the name field set to
-"file", and the filename field set to the relevant filename for the file.
-
-In addition, a `Content-MD5` header can be set with the MD5 hash of the file, to
-enable the server to check for consistency errors. If the supplied hash does not
-match the hash calculated on the server, a 412 Precondition Failed header will
-be issued.
-
-[RFC 2388]: http://tools.ietf.org/html/rfc2388
-
-### Response
-On a successful creation, a 201 Created status is given, indicating that the
-attachment has been created. The attachment is available canonically from the
-URL specified in the Location header.
-
-The new Attachment entity is also returned in the body for convienience.
</del><span class="cx">\ No newline at end of file
</span></span></pre></div>
<a id="2013rmccuetrunkdocsroutespostsmd"></a>
<div class="delfile"><h4>Deleted: 2013/rmccue/trunk/docs/routes-posts.md (2337 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/routes-posts.md 2013-09-21 09:04:26 UTC (rev 2337)
+++ 2013/rmccue/trunk/docs/routes-posts.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -1,126 +0,0 @@
</span><del>-Posts
-=====
-
-Retrieve Posts
---------------
-The Posts endpoint returns a Post Collection containing a subset of the site's
-posts.
-
- GET /posts
-
-### Input
-#### `filter`
-The `filter` parameter controls the query parameters. It is essentially a subset
-of the parameters available to [`WP_Query`](http://codex.wordpress.org/Class_Reference/WP_Query).
-
-The parameter should be an array of the following key/value pairs:
-
-* `post_status` - Comma-separated list of [status
- values](http://codex.wordpress.org/Class_Reference/WP_Query#Status_Parameters).
- Default is "publish". (string)
-* `numberposts` - Number of posts to retrieve, use `-1` for all posts. Default
- is set by the site. (integer)
-* `offset` - Number of posts to skip. Default is 0. (integer)
-* `orderby` - Parameter to search by, as per [WP Query](http://codex.wordpress.org/Class_Reference/WP_Query#Order_.26_Orderby_Parameters).
- Default is "date". (string)
-* `order` - Order to sort by. Default is "DESC". (string, "ASC" or "DESC")
-* `s` - Keyword to search for. (string)
-
-
-#### `fields`
-...
-
-
-#### `type`
-The `type` parameter specifies the post type to retrieve. Default is "post".
-(string)
-
-
-### Response
-The response is a Post Collection document containing the requested Posts if
-available.
-
-
-Create a Post
--------------
-
- POST /posts
-
-### Input
-The supplied data should be a Post object. This data can be submitted via a
-regular HTTP multipart body, with Post values set as values to the `data`
-parameter, or through a direct JSON body.
-
-That is, the following are equivalent:
-
-Content-Type: application/x-www-form-urlencoded
-
- data[post_title]=Hello%20World!&data[post_content]=Content
-
-
-Content-Type: application/json
-
- {"post_title":"Hello World!","post_content":"Content"}
-
-### Response
-On a successful creation, a 201 Created status is given, indicating that the
-post has been created. The post is available canonically from the URL specified
-in the Location header.
-
-The new Post entity is also returned in the body for convienience.
-
-
-Retrieve a Post
----------------
-
- GET /posts/<id>
-
-### Input
-#### `fields`
-...
-
-### Response
-The response is a Post entity containing the requested Post if available.
-
-
-Edit a Post
------------
-
- PUT /posts/<id>
-
-For compatibility reasons, this endpoint also accepts the POST and PATCH
-methods. Both of these methods have the same behaviour as using PUT. It is
-recommended to use PUT if available to fit with REST convention.
-
-### Input
-The supplied data should be a Post object. This data can be submitted via a
-regular HTTP multipart body, with Post values set as values to the `data`
-parameter, or through a direct JSON body. See the Create Post endpoint for an
-example.
-
-### Response
-On a successful update, a 200 OK status is given, indicating the post has been
-updated. The updated Post entity is returned in the body.
-
-
-Delete a Post
--------------
-
- DELETE /posts/<id>
-
-### Input
-#### `force`
-The `force` parameter controls whether the post is permanently deleted or not.
-By default, this is set to false, indicating that the post will be sent to an
-intermediate storage (such as the trash) allowing it to be restored later. If
-set to true, the post will not be able to be restored by the user.
-
-Default is false. (boolean)
-
-### Response
-On successful deletion, a 202 Accepted status code will be returned, indicating
-that the post has been moved to the trash for permanent deletion at a
-later date.
-
-If force was set to true, a 200 OK status code will be returned instead,
-indicating that the post has been permanently deleted.
</del><span class="cx">\ No newline at end of file
</span></span></pre></div>
<a id="2013rmccuetrunkdocsroutesmd"></a>
<div class="delfile"><h4>Deleted: 2013/rmccue/trunk/docs/routes.md (2337 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/routes.md 2013-09-21 09:04:26 UTC (rev 2337)
+++ 2013/rmccue/trunk/docs/routes.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -1,41 +0,0 @@
</span><del>-Notes
-=====
-
-### Inputting data as an "array"
-Endpoints may allow passing in an array of data, typically used for querying
-entities. URL semantics do not specify how to pass this, however the convention
-used by PHP and this API is to pass them with the array name concatenated with
-the key name in square brackets.
-
-For example:
-
- filter[post_status]=draft&filter[s]=foo
-
-
-### JSON data input
-Some posts allow directly passing JSON data (usually an entity) via the request
-body. These should be specified with a Content-Type header of `application/json`
-although individual endpoints may prefer more specific types.
-
-If your client platform does not support native JSON encoding, the data can be
-submitted via a regular HTTP multipart body, with properties set as values to
-the `data` parameter.
-
-That is, the following are equivalent:
-
-Content-Type: application/x-www-form-urlencoded
-
- data[post_title]=Hello%20World!&data[post_content]=Content
-
-
-Content-Type: application/json
-
- {"post_title":"Hello World!","post_content":"Content"}
-
-
-### HTTP method compatibility
-Due to their relatively new nature, some methods such as PATCH may not be
-supported by client software. To emulate support for this, a `_method` parameter
-may be passed via the URL with the value set to a valid HTTP method (DELETE,
-GET, HEAD, PATCH, POST, PUT, DELETE). Note that this must be passed via the URL
-and cannot be passed in the HTTP body.
</del></span></pre></div>
<a id="2013rmccuetrunkdocsschemamdfromrev23372013rmccuetrunkdocswpjsonmd"></a>
<div class="copfile"><h4>Copied: 2013/rmccue/trunk/docs/schema.md (from rev 2337, 2013/rmccue/trunk/docs/wp-json.md) (0 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/schema.md (rev 0)
+++ 2013/rmccue/trunk/docs/schema.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -0,0 +1,607 @@
</span><ins>+Introduction
+============
+The API is designed around two types of responses: entities, and collections.
+Entities are JSON objects representing internal objects, both abstract and
+WordPress objects. Collections are JSON arrays of Entities.
+
+
+Defintions
+==========
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
+interpreted as described in [RFC2119][].
+
+* Provider: A site making the API available for use
+* Consumer: An application accessing and interacting with the API
+* slug: A URL-friendly human-readable identifier, usually derived from the title
+ of the entity.
+
+[RFC2119]: http://tools.ietf.org/html/rfc2119
+
+
+### ABNF
+Augmented Backus-Naur Form (ABNF) is to be interpreted as described in
+[RFC5234][]. In addition, the following basic rules are used to describe basic
+parsing constructs above the standard JSON parsing rules.
+
+ token = 1*<any OCTET except CTLs> ; DQUOTE must be escaped with "\"
+
+Note that as per ABNF, literal strings are case insensitive. That is:
+
+ example-field = "id"
+ example-field = "ID"
+
+Providers SHOULD use the capitalisation as per this specification to ensure
+maximum compatibility with consumers. Consumers SHOULD ignore the case of
+literal strings when parsing data.
+
+[RFC5234]: http://tools.ietf.org/html/rfc5234
+
+
+Entities
+========
+
+Index
+-----
+The Index entity is a JSON object with site properties. The following properties
+are defined for the Index entity object.
+
+### `name`
+The `name` field is a string with the site's name.
+
+### `description`
+The `description` field is a string with the site's description.
+
+### `URL`
+The `URL` field is a string with the URL to the site itself.
+
+### `routes`
+The `routes` field is an object with keys as a route and the values as a route
+descriptor.
+
+The route is a string giving the URL template for the route, relative to the API
+root. The template contains URL parts separated by forward slashes, with each
+URL part either a static string, or a route variable encased in angle brackets.
+
+ route = ( "/"
+ / *( "/" ( token / route-variable ) ) )
+ route-variable = "<" token ">"
+
+These routes can be converted into URLs by replacing all route variables with
+their relevant values, then concatenating the relative URL to the API base.
+
+
+### `meta`
+The `meta` field is a Entity Meta entity with metadata relating to the entity
+representation.
+
+Typical `links` values for the meta object consist of a `help` key with the
+value indicating a human-readable documentation page about the API.
+
+
+Post
+----
+The Post entity is a JSON object of post properties. The following properties
+are defined for the Post entity object:
+
+### `title`
+The `title` field is a string with the post's title.
+
+### `date`, `date_gmt`
+The `date` and `date_gmt` fields are strings with the post's creation date and
+time in the local time and UTC respectively. These fields follow the [RFC3339][]
+Section 5.6 datetime representation.
+
+ date = date-time
+ date_gmt = date-time
+
+[RFC3339]: http://tools.ietf.org/html/rfc3339
+
+### `modified`, `modified_gmt`
+The `date` and `date_gmt` fields are strings with the post's last modification
+date and time in the local time and UTC respectively. These fields follow the
+[RFC3339][] Section 5.6 datetime representation.
+
+ modified = date-time
+ modified_gmt = date-time
+
+### `date_tz`, `modified_tz`
+The `date_tz` and `modified_tz` fields are strings with the timezone applying to
+the `date` and `modified` fields respectively. The timezone is a [Olsen zoneinfo
+database][] identifier. While the `date` and `modified` fields include timezone
+offset information, the `date_tz` and `modified_tz` fields allow proper data
+operations across Daylight Savings Time boundaries.
+
+Note that in addition to the normal Olsen timezones, manual offsets may be
+given. These manual offsets use the deprecated `Etc/GMT+...` zones and specify
+an integer offset in hours from UTC.
+
+ timezone = Olsen-timezone / manual-offset
+ manual-offset = "Etc/GMT" ("-" / "+") 1*2( DIGIT )
+
+Consumers SHOULD use the fields if they perform mathematical operations on the
+`date` and `modified` fields (such as adding an hour to the last modification
+date) rather than relying on the `time-offset` in the `date` or
+`modified` fields.
+
+[Olsen zoneinfo database]: https://en.wikipedia.org/wiki/Tz_database
+
+### `status`
+The `status` field is a string with the post's status. This status relates to
+where the post is in the editorial process. These are usually set values, but
+some providers may have extra post statuses.
+
+ post-status = "draft" / "pending" / "private" / "publish" / "trash" / token
+
+Consumers who encounter an unknown or missing post status SHOULD treat it the
+same as a "draft" status.
+
+### `type`
+The `type` field is a string with the post's type. This field is specific to
+providers, with the most basic representation being "post". The type of the
+post usually relates to the fields in the Post entity, with other types having
+additional fields specific to the type.
+
+ post-type = "post" / token
+
+Consumers who encounter an unknown or missing post type SHOULD treat it the same
+as a "post" type.
+
+### `name`
+The `name` field is a string with the post's slug.
+
+### `author`
+The `author` field is a User entity with the user who created the post.
+
+### `password`
+The `password` field is a string with the post's password. A zero-length
+password indicates that the post does not have a password.
+
+Consumers who encounter a missing password MUST treat it the same as a
+zero-length password.
+
+### `content`
+The `content` field is a string with the post's content.
+
+### `excerpt`
+The `excerpt` field is a string with the post's excerpt. This is usually a
+shortened version of the post content, suitable for displaying in
+collection views.
+
+Consumers who encounter a missing excerpt MAY present a shortened version of the
+`content` field instead.
+
+### `parent`
+The `parent` field is an integer with the post's parent post ID. A literal zero
+indicates that the post does not have a parent post.
+
+ post-parent = "0" / 1*DIGIT
+
+Consumers who encounter a missing parent ID MUST treat it the same as a parent
+post ID of 0.
+
+### `link`
+The `link` field is a string with the full URL to the post's canonical view.
+This is typically the human-readable location of the entity.
+
+### `guid`
+The `guid` field is a string with the post's globally unique identifier (GUID).
+
+The GUID is typically in URL form, as this is a relatively easy way of ensuring
+that the GUID is globally unique. However, consumers MUST NOT treat the GUID as
+a URL, and MUST treat the GUID as a string of arbitrary characters.
+
+### `menu_order`
+The `menu_order` field is an integer with the post's sorting position. This is
+typically used to affect sorting when displaying the post in menus or lists.
+Larger integers should be treated as sorting before smaller integers.
+
+ menu-order = 1*DIGIT / "-" 1*DIGIT
+
+Consumers who encounter a missing sorting position MUST treat it the same as a
+sorting position of 0.
+
+### `comment_status`
+The `comment_status` field is a string with the post's current commenting
+status. This field indicates whether users can submit comments to the post.
+
+ post-comment-status = "open" / "closed" / token
+
+Providers MAY use statuses other than "open" or "closed" to indicate other
+statuses. Consumers who encounter an unknown or missing comment status SHOULD
+treat it as "closed".
+
+### `ping_status`
+The `ping_status` field is a string with the post's current pingback/trackback
+status. This field indicates whether users can submit pingbacks or trackbacks
+to the post.
+
+ ping-status = "open" / "closed" / token
+
+Providers MAY use statuses other than "open" or "closed" to indicate other
+statuses. Consumers who encounter an unknown or missing ping status SHOULD treat
+it as "closed".
+
+### `sticky`
+The `sticky` field is a boolean indicating whether the post is marked as a
+sticky post. Consumers typically display sticky posts before other posts in
+collection views.
+
+### `post_thumbnail`
+The `post_thumbnail` field is a Media entity.
+
+### `post_format`
+The `post_format` field is a string with the post format. The post format
+indicates how some meta fields should be displayed. For example, posts with the
+"link" format may wish to display an extra link to a URL specified in a meta
+field or emphasise a link in the post content.
+
+ post-format = "standard" / "aside" / "gallery" / "image" / "link" / "status"
+
+Providers MUST NOT use post formats not specified by this specification, unless
+specified in a subsequent version of the specification. Consumers MUST treat
+unknown post formats as "standard".
+
+### `terms`
+The `terms` field is a Term collection.
+
+### `post_meta`
+The `meta` field is a Metadata entity with metadata relating to the post.
+
+### `meta`
+The `meta` field is a Entity Meta entity with metadata relating to the entity
+representation.
+
+
+Entity Meta
+-----------
+The Entity Meta entity is a JSON object with custom metadata relating to the
+representation of the parent entity.
+
+The following properties are defined for the Entity Meta entity object:
+
+### `links`
+The `links` field is a JSON object with hyperlinks to related entities. Each
+item's key is a link relation as per the [IANA Link Relations registry][] with
+the value of the item being the corresponding link URL.
+
+[IANA Link Relations registry]: http://www.iana.org/assignments/link-relations/link-relations.xml
+
+
+User
+----
+The User entity is a JSON object with user properties. The following properties
+are defined for the User entity object:
+
+### `ID`
+The `ID` field is an integer with the user's ID.
+
+### `name`
+The `name` field is a string with the user's display name.
+
+### `slug`
+The `slug` field is a string with the user's slug.
+
+### `URL`
+The `URL` field is a string with the URL to the author's site. This is typically
+an external link of the author's choice.
+
+### `avatar`
+The `avatar` field is a string with the URL to the author's avatar image.
+
+Providers SHOULD ensure that for users without an avatar image, this field is
+either zero-length or the URL returns a HTTP 404 error code on access. Consumers
+MAY display a default avatar instead of a zero-length or URL which returns
+a HTTP 404 error code.
+
+### `meta`
+The `meta` field is a Entity Meta entity with metadata relating to the entity
+representation.
+
+
+Metadata
+--------
+The Metadata entity is a JSON array with metadata fields. Each metadata field is
+a JSON object with `id`, `key` and `value` fields.
+
+### `id`
+The `id` field of the metadata field is a positive integer with the internal
+metadata ID.
+
+### `key`
+The `key` field of the metadata field is a string with the metadata field name.
+
+### `value`
+The `value` field of the metadata field is a string with the metadata
+field value.
+
+
+Comment
+-------
+The Comment entity is a JSON object with comment properties. The following
+properties are defined for the Comment entity object:
+
+### `ID`
+The `ID` field is an integer with the comment's ID.
+
+### `content`
+The `content` field is a string with the comment's content.
+
+### `status`
+The `status` field is a string with the comment's status. This field indicates
+whether the comment is in the publishing process, or if it has been deleted or
+marked as spam.
+
+ comment-status = "hold" / "approved" / "spam" / "trash" / token
+
+Providers MAY use other values to indicate other statuses. Consumers who
+encounter an unknown or missing status SHOULD treat it as "hold".
+
+### `type`
+The `type` field is a string with the comment's type. This is usually one of the
+following, but providers may provide additional values.
+
+ comment-type = "comment" / "trackback" / "pingback" / token
+
+Providers MAY use other values to indicate other types. Consumers who encounter
+an unknown or missing status SHOULD treat it as "comment".
+
+### `post`
+The `post` field is an integer with the parent post for the comment, or a Post
+entity describing the parent post. A literal zero indicates that the comment
+does not have a parent post.
+
+ comment-post-parent = "0" / 1*DIGIT
+
+Consumers who encounter a missing post ID MUST treat it the same as a parent
+post ID of 0.
+
+### `parent`
+The `post` field is an integer with the parent comment, or a Comment entity
+describing the parent comment. A literal zero indicates that the comment does
+not have a parent comment.
+
+ comment-parent = "0" / 1*DIGIT
+
+Consumers who encounter a missing parent ID MUST treat it the same as a parent
+comment ID of 0.
+
+### `author`
+The `author` field is a User entity with the comment author's data, or a
+User-like object for anonymous authors. The User-like object contains the
+following properties:
+
+#### `ID`
+The `ID` property on the User-like object is always set to `0` for anonymous
+authors.
+
+#### `name`
+The `name` property on the User-like object is a string with the author's name.
+
+#### `URL`
+The `URL` property on the User-like object is a string with the author's URL.
+
+#### `avatar`
+The `avatar` property on the User-like object is a string with the URL to the
+author's avatar image.
+
+This property should be treated the same as the avatar property on the
+User entity.
+
+
+### `date`, `date_gmt`
+The `date` and `date_gmt` fields are strings with the post's creation date and
+time in the local time and UTC respectively. These fields follow the [RFC3339][]
+Section 5.6 datetime representation.
+
+ date = date-time
+ date_gmt = date-time
+
+This field should be treated the same as the `date` and `date_gmt` properties on
+a Post entity.
+
+[RFC3339]: http://tools.ietf.org/html/rfc3339
+
+### `date_tz`, `modified_tz`
+The `date_tz` and `modified_tz` fields are strings with the timezone applying to
+the `date` and `modified` fields respectively. The timezone is a [Olsen zoneinfo
+database][] identifier. While the `date` field includes timezone offset
+information, the `date_tz` field allows proper data operations across Daylight
+Savings Time boundaries.
+
+This field should be treated the same as the `date_tz` property on a
+Post entity.
+
+
+Documents
+=========
+
+Index
+-----
+The Index document is the root endpoint for the API server and describes the
+contents and abilities of the API server.
+
+### Body
+The body of an Index document is an Index entity.
+
+### Example
+
+ {
+ "name":"My WordPress Site",
+ "description":"Just another WordPress site",
+ "URL":"http:\/\/example.com",
+ "routes": {
+ "\/": {
+ "supports": [ "HEAD", "GET" ]
+ },
+ "\/posts": {
+ "supports": [ "HEAD", "GET", "POST" ],
+ "accepts_json": true
+ },
+ "\/posts\/<id>": {
+ "supports": [ "HEAD", "GET", "POST", "PUT", "PATCH", "DELETE" ]
+ },
+ "\/posts\/<id>\/revisions": {
+ "supports": [ "HEAD", "GET" ]
+ },
+ "\/posts\/<id>\/comments": {
+ "supports": [ "HEAD", "GET", "POST" ],
+ "accepts_json":true
+ }
+ },
+ "meta": {
+ "links": {
+ "help":"http:\/\/codex.wordpress.org\/JSON_API"
+ }
+ }
+ }
+
+
+Post
+----
+A Post document is defined as the representation of a post item, analogous to an
+Atom item.
+
+### Headers
+The following headers are sent when a Post is the main entity:
+
+* `Link`:
+ * `rel="alternate"; type=text/html`: The permalink for the Post
+ * `rel="collection"`: The endpoint of the Post Collection the Post is
+ contained in
+ * `rel="replies"`: The endpoint of the associated Comment Collection
+ * `rel="version-history"`: The endpoint of the Post Collection containing
+ the revisions of the Post
+
+
+### Body
+The body of a Post document is a Post entity.
+
+
+### Example
+
+ HTTP/1.1 200 OK
+ Date: Mon, 07 Jan 2013 03:35:14 GMT
+ Last-Modified: Mon, 07 Jan 2013 03:35:14 GMT
+ Link: <http://localhost/wptrunk/?p=1>; rel="alternate"; type=text/html
+ Link: <http://localhost/wptrunk/wp-json.php/users/1>; rel="author"
+ Link: <http://localhost/wptrunk/wp-json.php/posts>; rel="collection"
+ Link: <http://localhost/wptrunk/wp-json.php/posts/158/comments>; rel="replies"
+ Link: <http://localhost/wptrunk/wp-json.php/posts/158/revisions>; rel="version-history"
+ Content-Type: application/json; charset=UTF-8
+
+ {
+ "ID":158,
+ "title":"This is a test!",
+ "status":"publish",
+ "type":"post",
+ "author":{
+ "ID":1,
+ "name":"admin",
+ "slug":"admin",
+ "URL":"",
+ "avatar":"http:\/\/0.gravatar.com\/avatar\/c57c8945079831fa3c19caef02e44614&d=404&r=G",
+ "meta":{
+ "links":{
+ "self":"http:\/\/localhost\/wptrunk\/wp-json.php\/users\/1",
+ "archives":"http:\/\/localhost\/wptrunk\/wp-json.php\/users\/1\/posts"
+ }
+ }
+ },
+ "content":"Hello.\r\n\r\nHah.",
+ "parent":0,
+ "link":"http:\/\/localhost\/wptrunk\/158\/this-is-a-test\/",
+ "date":"2013-01-07T13:35:14+10:00",
+ "modified":"2013-01-07T13:49:40+10:00",
+ "format":"standard",
+ "slug":"this-is-a-test",
+ "guid":"http:\/\/localhost\/wptrunk\/?p=158",
+ "excerpt":"",
+ "menu_order":0,
+ "comment_status":"open",
+ "ping_status":"open",
+ "sticky":false,
+ "date_tz":"Australia\/Brisbane",
+ "date_gmt":"2013-01-07T03:35:14+00:00",
+ "modified_tz":"Australia\/Brisbane",
+ "modified_gmt":"2013-01-07T03:49:40+00:00",
+ "post_thumbnail":[],
+ "terms":{
+ "category":{
+ "ID":1,
+ "name":"Uncategorized",
+ "slug":"uncategorized",
+ "group":0,
+ "parent":0,
+ "count":4,
+ "meta":{
+ "links":{
+ "collection":"http:\/\/localhost\/wptrunk\/wp-json.php\/taxonomy\/category",
+ "self":"http:\/\/localhost\/wptrunk\/wp-json.php\/taxonomy\/category\/terms\/1"
+ }
+ }
+ }
+ },
+ "post_meta":[],
+ "meta":{
+ "links":{
+ "self":"http:\/\/localhost\/wptrunk\/wp-json.php\/posts\/158",
+ "author":"http:\/\/localhost\/wptrunk\/wp-json.php\/users\/1",
+ "collection":"http:\/\/localhost\/wptrunk\/wp-json.php\/posts",
+ "replies":"http:\/\/localhost\/wptrunk\/wp-json.php\/posts\/158\/comments",
+ "version-history":"http:\/\/localhost\/wptrunk\/wp-json.php\/posts\/158\/revisions"
+ }
+ }
+ }
+
+
+Post Collection
+---------------
+A Post Collection document is defined as a collection of Post entities.
+
+### Headers
+The following headers are sent when a Post Collection is the main entity:
+
+* `Link`:
+ * `rel="item"` - Each item in the collection has a corresponding Link header
+ containing the location of the endpoint for that resource.
+
+
+### Body
+The Post Collection document is a JSON array of Post entities.
+
+
+User
+----
+The User document describes a member of the site.
+
+### Body
+The body of a User document is a User entity.
+
+
+Endpoints
+=========
+
+The following endpoints return the given document with associated headers.
+
+ /: Index
+ /posts: Post Collection
+ /posts/<id>: Post
+ /posts/<id>/revisions: Post Collection
+ /posts/<id>/comments: Comment Collection
+ /posts/<id>/comments/<comment>: Comment
+
+ /taxonomies: Taxonomy Collection
+ /taxonomies/<tax>: Taxonomy
+ /taxonomies/<tax>/terms: Term Collection
+ /taxonomies/<tax>/terms/<term>: Term
+
+ /users: User Collection
+ /users/me: User
+ /users/<user>: User
+
+
+Appendix A: JSON Schema
+=======================
+The JSON Schema describing the entities in this document is available in
+schema.json.
</ins></span></pre></div>
<a id="2013rmccuetrunkdocsschemamd"></a>
<div class="propset"><h4>Property changes: 2013/rmccue/trunk/docs/schema.md</h4>
<pre class="diff"><span>
</span></pre></div>
<a id="svnexecutable"></a>
<div class="addfile"><h4>Added: svn:executable</h4></div>
<ins>+*
</ins><span class="cx">\ No newline at end of property
</span><a id="2013rmccuetrunkdocswpjsonmd"></a>
<div class="delfile"><h4>Deleted: 2013/rmccue/trunk/docs/wp-json.md (2337 => 2338)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/wp-json.md 2013-09-21 09:04:26 UTC (rev 2337)
+++ 2013/rmccue/trunk/docs/wp-json.md 2013-09-21 09:04:38 UTC (rev 2338)
</span><span class="lines">@@ -1,607 +0,0 @@
</span><del>-Introduction
-============
-The API is designed around two types of responses: entities, and collections.
-Entities are JSON objects representing internal objects, both abstract and
-WordPress objects. Collections are JSON arrays of Entities.
-
-
-Defintions
-==========
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
-"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
-interpreted as described in [RFC2119][].
-
-* Provider: A site making the API available for use
-* Consumer: An application accessing and interacting with the API
-* slug: A URL-friendly human-readable identifier, usually derived from the title
- of the entity.
-
-[RFC2119]: http://tools.ietf.org/html/rfc2119
-
-
-### ABNF
-Augmented Backus-Naur Form (ABNF) is to be interpreted as described in
-[RFC5234][]. In addition, the following basic rules are used to describe basic
-parsing constructs above the standard JSON parsing rules.
-
- token = 1*<any OCTET except CTLs> ; DQUOTE must be escaped with "\"
-
-Note that as per ABNF, literal strings are case insensitive. That is:
-
- example-field = "id"
- example-field = "ID"
-
-Providers SHOULD use the capitalisation as per this specification to ensure
-maximum compatibility with consumers. Consumers SHOULD ignore the case of
-literal strings when parsing data.
-
-[RFC5234]: http://tools.ietf.org/html/rfc5234
-
-
-Entities
-========
-
-Index
------
-The Index entity is a JSON object with site properties. The following properties
-are defined for the Index entity object.
-
-### `name`
-The `name` field is a string with the site's name.
-
-### `description`
-The `description` field is a string with the site's description.
-
-### `URL`
-The `URL` field is a string with the URL to the site itself.
-
-### `routes`
-The `routes` field is an object with keys as a route and the values as a route
-descriptor.
-
-The route is a string giving the URL template for the route, relative to the API
-root. The template contains URL parts separated by forward slashes, with each
-URL part either a static string, or a route variable encased in angle brackets.
-
- route = ( "/"
- / *( "/" ( token / route-variable ) ) )
- route-variable = "<" token ">"
-
-These routes can be converted into URLs by replacing all route variables with
-their relevant values, then concatenating the relative URL to the API base.
-
-
-### `meta`
-The `meta` field is a Entity Meta entity with metadata relating to the entity
-representation.
-
-Typical `links` values for the meta object consist of a `help` key with the
-value indicating a human-readable documentation page about the API.
-
-
-Post
-----
-The Post entity is a JSON object of post properties. The following properties
-are defined for the Post entity object:
-
-### `title`
-The `title` field is a string with the post's title.
-
-### `date`, `date_gmt`
-The `date` and `date_gmt` fields are strings with the post's creation date and
-time in the local time and UTC respectively. These fields follow the [RFC3339][]
-Section 5.6 datetime representation.
-
- date = date-time
- date_gmt = date-time
-
-[RFC3339]: http://tools.ietf.org/html/rfc3339
-
-### `modified`, `modified_gmt`
-The `date` and `date_gmt` fields are strings with the post's last modification
-date and time in the local time and UTC respectively. These fields follow the
-[RFC3339][] Section 5.6 datetime representation.
-
- modified = date-time
- modified_gmt = date-time
-
-### `date_tz`, `modified_tz`
-The `date_tz` and `modified_tz` fields are strings with the timezone applying to
-the `date` and `modified` fields respectively. The timezone is a [Olsen zoneinfo
-database][] identifier. While the `date` and `modified` fields include timezone
-offset information, the `date_tz` and `modified_tz` fields allow proper data
-operations across Daylight Savings Time boundaries.
-
-Note that in addition to the normal Olsen timezones, manual offsets may be
-given. These manual offsets use the deprecated `Etc/GMT+...` zones and specify
-an integer offset in hours from UTC.
-
- timezone = Olsen-timezone / manual-offset
- manual-offset = "Etc/GMT" ("-" / "+") 1*2( DIGIT )
-
-Consumers SHOULD use the fields if they perform mathematical operations on the
-`date` and `modified` fields (such as adding an hour to the last modification
-date) rather than relying on the `time-offset` in the `date` or
-`modified` fields.
-
-[Olsen zoneinfo database]: https://en.wikipedia.org/wiki/Tz_database
-
-### `status`
-The `status` field is a string with the post's status. This status relates to
-where the post is in the editorial process. These are usually set values, but
-some providers may have extra post statuses.
-
- post-status = "draft" / "pending" / "private" / "publish" / "trash" / token
-
-Consumers who encounter an unknown or missing post status SHOULD treat it the
-same as a "draft" status.
-
-### `type`
-The `type` field is a string with the post's type. This field is specific to
-providers, with the most basic representation being "post". The type of the
-post usually relates to the fields in the Post entity, with other types having
-additional fields specific to the type.
-
- post-type = "post" / token
-
-Consumers who encounter an unknown or missing post type SHOULD treat it the same
-as a "post" type.
-
-### `name`
-The `name` field is a string with the post's slug.
-
-### `author`
-The `author` field is a User entity with the user who created the post.
-
-### `password`
-The `password` field is a string with the post's password. A zero-length
-password indicates that the post does not have a password.
-
-Consumers who encounter a missing password MUST treat it the same as a
-zero-length password.
-
-### `content`
-The `content` field is a string with the post's content.
-
-### `excerpt`
-The `excerpt` field is a string with the post's excerpt. This is usually a
-shortened version of the post content, suitable for displaying in
-collection views.
-
-Consumers who encounter a missing excerpt MAY present a shortened version of the
-`content` field instead.
-
-### `parent`
-The `parent` field is an integer with the post's parent post ID. A literal zero
-indicates that the post does not have a parent post.
-
- post-parent = "0" / 1*DIGIT
-
-Consumers who encounter a missing parent ID MUST treat it the same as a parent
-post ID of 0.
-
-### `link`
-The `link` field is a string with the full URL to the post's canonical view.
-This is typically the human-readable location of the entity.
-
-### `guid`
-The `guid` field is a string with the post's globally unique identifier (GUID).
-
-The GUID is typically in URL form, as this is a relatively easy way of ensuring
-that the GUID is globally unique. However, consumers MUST NOT treat the GUID as
-a URL, and MUST treat the GUID as a string of arbitrary characters.
-
-### `menu_order`
-The `menu_order` field is an integer with the post's sorting position. This is
-typically used to affect sorting when displaying the post in menus or lists.
-Larger integers should be treated as sorting before smaller integers.
-
- menu-order = 1*DIGIT / "-" 1*DIGIT
-
-Consumers who encounter a missing sorting position MUST treat it the same as a
-sorting position of 0.
-
-### `comment_status`
-The `comment_status` field is a string with the post's current commenting
-status. This field indicates whether users can submit comments to the post.
-
- post-comment-status = "open" / "closed" / token
-
-Providers MAY use statuses other than "open" or "closed" to indicate other
-statuses. Consumers who encounter an unknown or missing comment status SHOULD
-treat it as "closed".
-
-### `ping_status`
-The `ping_status` field is a string with the post's current pingback/trackback
-status. This field indicates whether users can submit pingbacks or trackbacks
-to the post.
-
- ping-status = "open" / "closed" / token
-
-Providers MAY use statuses other than "open" or "closed" to indicate other
-statuses. Consumers who encounter an unknown or missing ping status SHOULD treat
-it as "closed".
-
-### `sticky`
-The `sticky` field is a boolean indicating whether the post is marked as a
-sticky post. Consumers typically display sticky posts before other posts in
-collection views.
-
-### `post_thumbnail`
-The `post_thumbnail` field is a Media entity.
-
-### `post_format`
-The `post_format` field is a string with the post format. The post format
-indicates how some meta fields should be displayed. For example, posts with the
-"link" format may wish to display an extra link to a URL specified in a meta
-field or emphasise a link in the post content.
-
- post-format = "standard" / "aside" / "gallery" / "image" / "link" / "status"
-
-Providers MUST NOT use post formats not specified by this specification, unless
-specified in a subsequent version of the specification. Consumers MUST treat
-unknown post formats as "standard".
-
-### `terms`
-The `terms` field is a Term collection.
-
-### `post_meta`
-The `meta` field is a Metadata entity with metadata relating to the post.
-
-### `meta`
-The `meta` field is a Entity Meta entity with metadata relating to the entity
-representation.
-
-
-Entity Meta
------------
-The Entity Meta entity is a JSON object with custom metadata relating to the
-representation of the parent entity.
-
-The following properties are defined for the Entity Meta entity object:
-
-### `links`
-The `links` field is a JSON object with hyperlinks to related entities. Each
-item's key is a link relation as per the [IANA Link Relations registry][] with
-the value of the item being the corresponding link URL.
-
-[IANA Link Relations registry]: http://www.iana.org/assignments/link-relations/link-relations.xml
-
-
-User
-----
-The User entity is a JSON object with user properties. The following properties
-are defined for the User entity object:
-
-### `ID`
-The `ID` field is an integer with the user's ID.
-
-### `name`
-The `name` field is a string with the user's display name.
-
-### `slug`
-The `slug` field is a string with the user's slug.
-
-### `URL`
-The `URL` field is a string with the URL to the author's site. This is typically
-an external link of the author's choice.
-
-### `avatar`
-The `avatar` field is a string with the URL to the author's avatar image.
-
-Providers SHOULD ensure that for users without an avatar image, this field is
-either zero-length or the URL returns a HTTP 404 error code on access. Consumers
-MAY display a default avatar instead of a zero-length or URL which returns
-a HTTP 404 error code.
-
-### `meta`
-The `meta` field is a Entity Meta entity with metadata relating to the entity
-representation.
-
-
-Metadata
---------
-The Metadata entity is a JSON array with metadata fields. Each metadata field is
-a JSON object with `id`, `key` and `value` fields.
-
-### `id`
-The `id` field of the metadata field is a positive integer with the internal
-metadata ID.
-
-### `key`
-The `key` field of the metadata field is a string with the metadata field name.
-
-### `value`
-The `value` field of the metadata field is a string with the metadata
-field value.
-
-
-Comment
--------
-The Comment entity is a JSON object with comment properties. The following
-properties are defined for the Comment entity object:
-
-### `ID`
-The `ID` field is an integer with the comment's ID.
-
-### `content`
-The `content` field is a string with the comment's content.
-
-### `status`
-The `status` field is a string with the comment's status. This field indicates
-whether the comment is in the publishing process, or if it has been deleted or
-marked as spam.
-
- comment-status = "hold" / "approved" / "spam" / "trash" / token
-
-Providers MAY use other values to indicate other statuses. Consumers who
-encounter an unknown or missing status SHOULD treat it as "hold".
-
-### `type`
-The `type` field is a string with the comment's type. This is usually one of the
-following, but providers may provide additional values.
-
- comment-type = "comment" / "trackback" / "pingback" / token
-
-Providers MAY use other values to indicate other types. Consumers who encounter
-an unknown or missing status SHOULD treat it as "comment".
-
-### `post`
-The `post` field is an integer with the parent post for the comment, or a Post
-entity describing the parent post. A literal zero indicates that the comment
-does not have a parent post.
-
- comment-post-parent = "0" / 1*DIGIT
-
-Consumers who encounter a missing post ID MUST treat it the same as a parent
-post ID of 0.
-
-### `parent`
-The `post` field is an integer with the parent comment, or a Comment entity
-describing the parent comment. A literal zero indicates that the comment does
-not have a parent comment.
-
- comment-parent = "0" / 1*DIGIT
-
-Consumers who encounter a missing parent ID MUST treat it the same as a parent
-comment ID of 0.
-
-### `author`
-The `author` field is a User entity with the comment author's data, or a
-User-like object for anonymous authors. The User-like object contains the
-following properties:
-
-#### `ID`
-The `ID` property on the User-like object is always set to `0` for anonymous
-authors.
-
-#### `name`
-The `name` property on the User-like object is a string with the author's name.
-
-#### `URL`
-The `URL` property on the User-like object is a string with the author's URL.
-
-#### `avatar`
-The `avatar` property on the User-like object is a string with the URL to the
-author's avatar image.
-
-This property should be treated the same as the avatar property on the
-User entity.
-
-
-### `date`, `date_gmt`
-The `date` and `date_gmt` fields are strings with the post's creation date and
-time in the local time and UTC respectively. These fields follow the [RFC3339][]
-Section 5.6 datetime representation.
-
- date = date-time
- date_gmt = date-time
-
-This field should be treated the same as the `date` and `date_gmt` properties on
-a Post entity.
-
-[RFC3339]: http://tools.ietf.org/html/rfc3339
-
-### `date_tz`, `modified_tz`
-The `date_tz` and `modified_tz` fields are strings with the timezone applying to
-the `date` and `modified` fields respectively. The timezone is a [Olsen zoneinfo
-database][] identifier. While the `date` field includes timezone offset
-information, the `date_tz` field allows proper data operations across Daylight
-Savings Time boundaries.
-
-This field should be treated the same as the `date_tz` property on a
-Post entity.
-
-
-Documents
-=========
-
-Index
------
-The Index document is the root endpoint for the API server and describes the
-contents and abilities of the API server.
-
-### Body
-The body of an Index document is an Index entity.
-
-### Example
-
- {
- "name":"My WordPress Site",
- "description":"Just another WordPress site",
- "URL":"http:\/\/example.com",
- "routes": {
- "\/": {
- "supports": [ "HEAD", "GET" ]
- },
- "\/posts": {
- "supports": [ "HEAD", "GET", "POST" ],
- "accepts_json": true
- },
- "\/posts\/<id>": {
- "supports": [ "HEAD", "GET", "POST", "PUT", "PATCH", "DELETE" ]
- },
- "\/posts\/<id>\/revisions": {
- "supports": [ "HEAD", "GET" ]
- },
- "\/posts\/<id>\/comments": {
- "supports": [ "HEAD", "GET", "POST" ],
- "accepts_json":true
- }
- },
- "meta": {
- "links": {
- "help":"http:\/\/codex.wordpress.org\/JSON_API"
- }
- }
- }
-
-
-Post
-----
-A Post document is defined as the representation of a post item, analogous to an
-Atom item.
-
-### Headers
-The following headers are sent when a Post is the main entity:
-
-* `Link`:
- * `rel="alternate"; type=text/html`: The permalink for the Post
- * `rel="collection"`: The endpoint of the Post Collection the Post is
- contained in
- * `rel="replies"`: The endpoint of the associated Comment Collection
- * `rel="version-history"`: The endpoint of the Post Collection containing
- the revisions of the Post
-
-
-### Body
-The body of a Post document is a Post entity.
-
-
-### Example
-
- HTTP/1.1 200 OK
- Date: Mon, 07 Jan 2013 03:35:14 GMT
- Last-Modified: Mon, 07 Jan 2013 03:35:14 GMT
- Link: <http://localhost/wptrunk/?p=1>; rel="alternate"; type=text/html
- Link: <http://localhost/wptrunk/wp-json.php/users/1>; rel="author"
- Link: <http://localhost/wptrunk/wp-json.php/posts>; rel="collection"
- Link: <http://localhost/wptrunk/wp-json.php/posts/158/comments>; rel="replies"
- Link: <http://localhost/wptrunk/wp-json.php/posts/158/revisions>; rel="version-history"
- Content-Type: application/json; charset=UTF-8
-
- {
- "ID":158,
- "title":"This is a test!",
- "status":"publish",
- "type":"post",
- "author":{
- "ID":1,
- "name":"admin",
- "slug":"admin",
- "URL":"",
- "avatar":"http:\/\/0.gravatar.com\/avatar\/c57c8945079831fa3c19caef02e44614&d=404&r=G",
- "meta":{
- "links":{
- "self":"http:\/\/localhost\/wptrunk\/wp-json.php\/users\/1",
- "archives":"http:\/\/localhost\/wptrunk\/wp-json.php\/users\/1\/posts"
- }
- }
- },
- "content":"Hello.\r\n\r\nHah.",
- "parent":0,
- "link":"http:\/\/localhost\/wptrunk\/158\/this-is-a-test\/",
- "date":"2013-01-07T13:35:14+10:00",
- "modified":"2013-01-07T13:49:40+10:00",
- "format":"standard",
- "slug":"this-is-a-test",
- "guid":"http:\/\/localhost\/wptrunk\/?p=158",
- "excerpt":"",
- "menu_order":0,
- "comment_status":"open",
- "ping_status":"open",
- "sticky":false,
- "date_tz":"Australia\/Brisbane",
- "date_gmt":"2013-01-07T03:35:14+00:00",
- "modified_tz":"Australia\/Brisbane",
- "modified_gmt":"2013-01-07T03:49:40+00:00",
- "post_thumbnail":[],
- "terms":{
- "category":{
- "ID":1,
- "name":"Uncategorized",
- "slug":"uncategorized",
- "group":0,
- "parent":0,
- "count":4,
- "meta":{
- "links":{
- "collection":"http:\/\/localhost\/wptrunk\/wp-json.php\/taxonomy\/category",
- "self":"http:\/\/localhost\/wptrunk\/wp-json.php\/taxonomy\/category\/terms\/1"
- }
- }
- }
- },
- "post_meta":[],
- "meta":{
- "links":{
- "self":"http:\/\/localhost\/wptrunk\/wp-json.php\/posts\/158",
- "author":"http:\/\/localhost\/wptrunk\/wp-json.php\/users\/1",
- "collection":"http:\/\/localhost\/wptrunk\/wp-json.php\/posts",
- "replies":"http:\/\/localhost\/wptrunk\/wp-json.php\/posts\/158\/comments",
- "version-history":"http:\/\/localhost\/wptrunk\/wp-json.php\/posts\/158\/revisions"
- }
- }
- }
-
-
-Post Collection
----------------
-A Post Collection document is defined as a collection of Post entities.
-
-### Headers
-The following headers are sent when a Post Collection is the main entity:
-
-* `Link`:
- * `rel="item"` - Each item in the collection has a corresponding Link header
- containing the location of the endpoint for that resource.
-
-
-### Body
-The Post Collection document is a JSON array of Post entities.
-
-
-User
-----
-The User document describes a member of the site.
-
-### Body
-The body of a User document is a User entity.
-
-
-Endpoints
-=========
-
-The following endpoints return the given document with associated headers.
-
- /: Index
- /posts: Post Collection
- /posts/<id>: Post
- /posts/<id>/revisions: Post Collection
- /posts/<id>/comments: Comment Collection
- /posts/<id>/comments/<comment>: Comment
-
- /taxonomies: Taxonomy Collection
- /taxonomies/<tax>: Taxonomy
- /taxonomies/<tax>/terms: Term Collection
- /taxonomies/<tax>/terms/<term>: Term
-
- /users: User Collection
- /users/me: User
- /users/<user>: User
-
-
-Appendix A: JSON Schema
-=======================
-The JSON Schema describing the entities in this document is available in
-schema.json.
</del></span></pre>
</div>
</div>
</body>
</html>