<!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>[2145] 2013/rmccue/trunk/docs: Add guiding principles and further notes</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/2145">2145</a></dd>
<dt>Author</dt> <dd>rmccue</dd>
<dt>Date</dt> <dd>2013-07-23 12:44:16 +0000 (Tue, 23 Jul 2013)</dd>
</dl>
<h3>Log Message</h3>
<pre>Add guiding principles and further notes</pre>
<h3>Added 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>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="2013rmccuetrunkdocsimplementationmd"></a>
<div class="addfile"><h4>Added: 2013/rmccue/trunk/docs/implementation.md (0 => 2145)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/implementation.md (rev 0)
+++ 2013/rmccue/trunk/docs/implementation.md 2013-07-23 12:44:16 UTC (rev 2145)
</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 class="cx">Property changes on: 2013/rmccue/trunk/docs/implementation.md
</span><span class="cx">___________________________________________________________________
</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="2013rmccuetrunkdocsphilosophymd"></a>
<div class="addfile"><h4>Added: 2013/rmccue/trunk/docs/philosophy.md (0 => 2145)</h4>
<pre class="diff"><span>
<span class="info">--- 2013/rmccue/trunk/docs/philosophy.md (rev 0)
+++ 2013/rmccue/trunk/docs/philosophy.md 2013-07-23 12:44:16 UTC (rev 2145)
</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 class="cx">Property changes on: 2013/rmccue/trunk/docs/philosophy.md
</span><span class="cx">___________________________________________________________________
</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></div>
</body>
</html>