StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POdeveloping a maintainable RPC system
text
Body
copied!<p>I am working on a web application that will make extensive use of AJAX techniques for client/server communication...JSON-RPC specifically. Zend Framework is being used server-side, and it offers a nice JSON-RPC server that I would like to use.</p> <p>My goal is to architect a maintainable system that exposes a <em>large</em> subset of server-side functionality to the client-side (javascript), without unnecessary code duplication. I've seen numerous blog posts and tutorials on how to use ZF's JSON-RPC server (see <a href="http://dustint.com/archives/20" rel="nofollow">here</a> and <a href="http://sourcecodebean.com/archives/creating-a-json-rpc-service-using-zend-json-server/422" rel="nofollow">here</a>), but they all seemed geared towards exposing a small, publicly consumable API. Code duplication is common, for example one blog post has the following method exposed:</p> <pre><code>public static function setTitle($bookId, $title) { $book = new Nickel_Model_Book($bookId); $book->setTitle($title); $book->update(); return true; } </code></pre> <p>I don't like the fact that there are two <code>setTitle</code> methods. If the method signature for one changes, the other has to be kept in sync...seems like a maintainability nightmare if your API is extensive. It seems to me that there should be one <code>Book</code> class, with one <code>setTitle</code> method.</p> <p>My initial thought is add a docblock annotation <code>@export</code> to methods/classes that I want exposed. When I decide to expose the <code>setTitle</code> method, I just add the annotation rather than a new method.</p> <p>One potential problem I see involves object persistence. Server-side, it makes sense for <code>setTitle</code> to set the object's title property...but not persist it in the database until <code>update()</code> is called. Client-side, calling <code>setTitle</code> should immediately affect the database. One potential solution is to modify all accessors such that they take a optional second parameter signifying the modification should update the database immediately:</p> <pre><code>function setTitle($title, $persist = false) { $this->title = $title; if ($persist) $this->update(); } </code></pre> <p>Some sort of proxy class could ensure that the <code>$persist</code> flag is set for all client-side RPC invocations.</p> <p>Another problem is the serialization of PHP objects. Server-side, it makes sense to do a OO-style <code>$book->setTitle("foo")</code> call, but client-side <code>book.setTitle(1234, "foo")</code> makes sense (where 1234 is the book's ID) due to the lack of state. My solution for this would be to have the aforementioned proxy class be responsible for somehow turning <code>book.setTitle(1234, "foo")</code> into:</p> <pre><code>$book = new Book(); $book->load(1234); return $book->setTitle($title); </code></pre> <p>I feel like this problem must have been tackled or discussed before...but I'm not finding many resources online. Does this seem like a sane solution?</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload