<blockquote>
<p>Martel,</p>

<p>I actually started working on this again recently for a project and I ended up writing a Zend_Controller_Router_Rest class instead of a specific Route class. I updated my proposal in the wiki and would appreciate some feedback from you before I announce it to the mailing list. It actually works for me, but I'm sure it could use some cleanup and such ...</p></blockquote>

<p>Luke, I don't really see anything in there that couldn't be used in the route class instead of a router. While overriding the router you're basically removing support for chaining different types of routing. And you render the URL view helper useless. And that's all. That's what you get by doing it in the router instead of a route class. </p>

<p>If you leave automatic module detection out, you don't even need the dispatcher instance (and router in fact shouldn't be aware of the dispatcher). All you need is the request object which will be passed to route instances in a very near future. </p>

<p>What is the status of this class? What is the preferred method of implementing a RESTful Web Service?</p>

<p>I've updated the use-case and class code of this proposal to match Route behavior of ZF 1.7.2. What are next steps for moving it into incubator?</p>

<p>I'm not sure I agree with the URI/request method mappings you outlined under "Theory of Operation". Traditional REST would do the following:</p>

<table><tbody>
<tr>
<th><p>Request Method</p></th>
<th><p>URI</p></th>
<th><p>Module_Controller::action</p></th>
</tr>
<tr>
<td><p>GET</p></td>
<td><p>/product/ratings</p></td>
<td><p>Product_Ratings::listAction()</p></td>
</tr>
<tr>
<td><p>GET</p></td>
<td><p>/product/ratings/:id</p></td>
<td><p>Product_Ratings::getAction()</p></td>
</tr>
<tr>
<td><p>POST</p></td>
<td><p>/product/ratings</p></td>
<td><p>Product_Ratings::newAction()</p></td>
</tr>
<tr>
<td><p>PUT</p></td>
<td><p>/product/ratings/:id</p></td>
<td><p>Product_Ratings::updateAction()</p></td>
</tr>
<tr>
<td><p>DELETE</p></td>
<td><p>/product/ratings/:id</p></td>
<td><p>Product_Ratings::deleteAction()</p></td>
</tr>
<tr>
<td><p>POST</p></td>
<td><p>/product/ratings/:id</p></td>
<td><p>Product_Ratings::updateAction()</p></td>
</tr>
<tr>
<td><p>POST</p></td>
<td><p>/product/ratings/:id?delete</p></td>
<td><p>Product_Ratings::deleteAction()</p></td>
</tr>
</tbody></table>

<p>The differences are around how get/new/update/delete work. When you POST with an identifier, it acts as an update; without an identifier, it attempts to create a new item. </p>

<p>Otherwise, the proposed solution makes sense.</p>

<p>One other item: It seems like this should include an extension to Zend_Controller_Action – perhaps Zend_Controller_Action_Rest and/or Zend_Controller_Action_Rest_Interface? That would simplify the creation of REST controllers, and ensure that they would work with the route.</p>

<ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Acceptance</ac:parameter><ac:rich-text-body>
<p>This proposal is accepted for immediate development in the standard incubator. However, there are several changes/issues we would like to see addressed:</p>

<ul>
<li>Rename to Zend_Rest_Route and Zend_Rest_Controller</li>
<li>Do not inject the dispatcher and request object in the route constructor. Instead, allow for optional injection of the front controller. As the dispatcher and request object could change prior to routing, injecting the front controller (or, if not present, pulling the singleton instance) will allow retrieving the instances as registered at execution time.</li>
<li>The abstract Zend_Rest_Controller should <strong>not</strong> include the newAction and editAction methods, but the route should still allow for them. The Zend team's feeling is that while these may be useful in REST applications that utilize HTML, the majority of REST applications will likely not utilize them, and the controller should not enforce their existence.</li>
<li>The route should allow each of the following scenarios:
<ul>
<li>Acting as a fallback route, and route all matched requests as RESTful actions (this is the usage shown already in UC-01)</li>
<li>Allow registering a specific module or array of modules as containing controllers with RESTful actions:
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
// Only the module "api":
$restfulRoutes = new Zend_Rest_Route('api', $front);

// The modules "xml" and "json":
$restfulRoutes = new Zend_Rest_Route(array('xml', 'json'), $front);
]]></ac:plain-text-body></ac:macro></li>
<li>Allow registering specific module => controller combinations as RESTful controllers:
<ac:macro ac:name="code"><ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
// The Service_RestController only:
$restfulRoute = new Zend_Rest_Route(array('service' => array('rest')), $front);

// The controllers: Json_RestController, Service_RestController, and Service_JsonController:
$restfulRoute = new Zend_Rest_Route(
array(
'json' => array('rest'),
'service' => array('rest', 'json'),
),
$front
);
]]></ac:plain-text-body></ac:macro>
We feel that this API would allow for mixing RESTful controllers with other application controllers.</li>
</ul>
</li>
<li>Finally, we have one concern regarding the matching of request method tokens. It cannot be assumed that the request is using a payload in a specific format; the request could be in JSON, XML, YAML, etc. As such, we request that if the matching is format specific, different subclasses be created for each specific format you intend to support (Zend_Rest_Route_Json, Zend_Rest_Route_Xml, etc.).</li>
</ul>
</ac:rich-text-body></ac:macro>

<p>Does this solution allows to submit identifier with Umlauts and Slashes?</p>

<p>Example Use Case:<br />
It should be possible to update products with the following identifiers:</p>
<ul class="alternate">
<li>ProductId: "Mü/120/abc"</li>
<li>ProductId: "Aß/230/def"</li>
</ul>

<p>In this Use Case the identifiers contains Slashes as well as Umlauts. Submitting identifiers with slashes (and different character sets) shouldn't lead to misinterpreted parameters.</p>

<p>Remi</p>

<p>I've updated the proposal and code to meet the acceptance criteria. Couple of things discussed but not implemented ...</p>

<p>I didn't drop the key-value URI scheme because I have found it easier to implement a flexible 'index' action - i.e., one that accepts an assortment of filtering params like /new_since/:timestamp/changed_since/:timestamp - if each of the params retain names. As I consider this though, I could change the route to pass key-value URI params for the 'index' route only, and all other routes could operate from the /:module/:controller/:identifier scheme. How important is this feature?</p>

<p>I left the putAction as putAction, simply because the route code is getting a little complex already, and also because I think it helps to reinforce users' implementation of the HTTP uniform interface in their controllers. Again I could re-consider this if we think it's very important.</p>

<p>Also, I need a bit of coaching on my next steps. I <strong>think</strong> I have svn access, but can I simply check-out the standard incubator repos? How's the best way to set up a test project to use my Zend_Rest stuff from the incubator repos but use Zend_Controller from regular repos?</p>

<p>Could support for the X-HTTP-Method-Override header be included to supplement the _method parameter for clients that (for whatever reason) offer limited or no support for methods other than GET and POST?</p>

<p>Luke, do you plan to have this ready for 1.8?</p>

<p>Surely I'm a little lost, but I cannot find your proposal at the standard incubator repository. Where it is?</p>

<p> On the other hand, you said:
<br class="atl-forced-newline" /></p>
<blockquote>
<p>As I consider this though, I could change the route to pass key-value URI params for the 'index' route only, and all other routes could operate from the /:module/:controller/:identifier scheme. How important is this feature?</p></blockquote>
<p>I think this is a very important feature because it will allow a better integration with <a href="http://docs.dojocampus.org/dojox/data/JsonRestStore">dojox.data.JsonRestStore</a></p>

<p>Hi,</p>

<p>Zend_Rest_Route::_checkRestfulModule() throw a E_WARNING on modules not declared in the __construct</p>

<p>Quick fix :</p>
<ac:macro ac:name="code"><ac:plain-text-body><![CDATA[

• if ($this->_restfulControllers && array_search($controllerName, $this->_restfulControllers[$moduleName]) !== false)
  + if ($this->_restfulControllers && array_key_exists($moduleName, $this->_restfulControllers) && array_search($controllerName, $this->_restfulControllers[$moduleName]) !== false)
  ]]></ac:plain-text-body></ac:macro>