Previous Next

The Standard Router

Introduction

Zend_Controller_Router_Rewrite is the standard framework router. Routing is the process of taking a URI endpoint (that part of the URI which comes after the base URL) and decomposing it into parameters to determine which module, controller, and action of that controller should receive the request. This values of the module, controller, action and other parameters are packaged into a Zend_Controller_Request_Http object which is then processed by Zend_Controller_Dispatcher_Standard. Routing occurs only once: when the request is initially received and before the first controller is dispatched.

Zend_Controller_Router_Rewrite is designed to allow for mod_rewrite-like functionality using pure PHP structures. It is very loosely based on Ruby on Rails routing and does not require any prior knowledge of webserver URL rewriting. It is designed to work with a single Apache mod_rewrite rule (one of):

RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css|html)$ index.php

or (preferred):

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

The rewrite router can also be used with the IIS webserver (versions <= 7.0) if » Isapi_Rewrite has been installed as an Isapi extension with the following rewrite rule:

RewriteRule ^[\w/\%]*(?:\.(?!(?:js|ico|gif|jpg|png|css|html)$)[\w\%]*$)? /index.php [I]

Note: IIS Isapi_Rewrite

When using IIS, $_SERVER['REQUEST_URI'] will either not exist, or be set as an empty string. In this case, Zend_Controller_Request_Http will attempt to use the $_SERVER['HTTP_X_REWRITE_URL'] value set by the Isapi_Rewrite extension.

IIS 7.0 introduces a native URL rewriting module, and it can be configured as follows:



     
         
             
                 
                     
                     
                         
                         
                     
                     
                 
                 
                     
                     
                 
             
         
     

If using Lighttpd, the following rewrite rule is valid:

url.rewrite-once = (
    ".*\?(.*)$" => "/index.php?$1",
    ".*\.(js|ico|gif|jpg|png|css|html)$" => "$0",
    "" => "/index.php"
)

Using a Router

To properly use the rewrite router you have to instantiate it, add some user defined routes and inject it into the controller. The following code illustrates the procedure:

// Create a router

$router = $ctrl->getRouter(); // returns a rewrite router by default
$router->addRoute(
    'user',
    new Zend_Controller_Router_Route('user/:username',
                                     array('controller' => 'user',
                                           'action' => 'info'))
);

Basic Rewrite Router Operation

The heart of the RewriteRouter is the definition of user defined routes. Routes are added by calling the addRoute method of RewriteRouter and passing in a new instance of a class implementing Zend_Controller_Router_Route_Interface. Eg.:

$router->addRoute('user',
                  new Zend_Controller_Router_Route('user/:username'));

Rewrite Router comes with six basic types of routes (one of which is special):

Routes may be used numerous times to create a chain or user defined application routing schema. You may use any number of routes in any configuration, with the exception of the Module route, which should rather be used once and probably as the most generic route (i.e., as a default). Each route will be described in greater detail later on.

The first parameter to addRoute is the name of the route. It is used as a handle for getting the routes out of the router (e.g., for URL generation purposes). The second parameter being the route itself.

Note:

The most common use of the route name is through the means of Zend_View url helper:

Martel

Which would result in the href: user/martel.

Routing is a simple process of iterating through all provided routes and matching its definitions to current request URI. When a positive match is found, variable values are returned from the Route instance and are injected into the Zend_Controller_Request object for later use in the dispatcher as well as in user created controllers. On a negative match result, the next route in the chain is checked.

If you need to determine which route was matched, you can use the getCurrentRouteName() method, which will return the identifier used when registering the route with the router. If you want the actual route object, you can use getCurrentRoute().

Note: Reverse Matching

Routes are matched in reverse order so make sure your most generic routes are defined first.

Note: Returned Values

Values returned from routing come from URL parameters or user defined route defaults. These variables are later accessible through the Zend_Controller_Request::getParam() or Zend_Controller_Action::_getParam() methods.

There are three special variables which can be used in your routes - 'module', 'controller' and 'action'. These special variables are used by Zend_Controller_Dispatcher to find a controller and action to dispatch to.

Note: Special Variables

The names of these special variables may be different if you choose to alter the defaults in Zend_Controller_Request_Http by means of the setControllerKey() and setActionKey() methods.

Default Routes

Zend_Controller_Router_Rewrite comes preconfigured with a default route, which will match URIs in the shape of controller/action. Additionally, a module name may be specified as the first path element, allowing URIs of the form module/controller/action. Finally, it will also match any additional parameters appended to the URI by default - controller/action/var1/value1/var2/value2.

Some examples of how such routes are matched:

// Assuming the following:
$ctrl->setControllerDirectory(
    array(
        'default' => '/path/to/default/controllers',
        'news'    => '/path/to/news/controllers',
        'blog'    => '/path/to/blog/controllers'
    )
);

Module only:
http://example/news
    module == news

Invalid module maps to controller name:
http://example/foo
    controller == foo

Module + controller:
http://example/blog/archive
    module     == blog
    controller == archive

Module + controller + action:
http://example/blog/archive/list
    module     == blog
    controller == archive
    action     == list

Module + controller + action + params:
http://example/blog/archive/list/sort/alpha/date/desc
    module     == blog
    controller == archive
    action     == list
    sort       == alpha
    date       == desc

The default route is simply a Zend_Controller_Router_Route_Module object stored under the name (index) of 'default' in RewriteRouter. It's created more-or-less like below:

$compat = new Zend_Controller_Router_Route_Module(array(),
                                                  $dispatcher,
                                                  $request);
$this->addRoute('default', $compat);

If you do not want this particular default route in your routing schema, you may override it by creating your own 'default' route (i.e., storing it under the name of 'default') or removing it altogether by using removeDefaultRoutes():

// Remove any default routes
$router->removeDefaultRoutes();

Base URL and Subdirectories

The rewrite router can be used in subdirectories (e.g., http://domain.com/user/application-root/) in which case the base URL of the application (/user/application-root) should be automatically detected by Zend_Controller_Request_Http and used accordingly.

Should the base URL be detected incorrectly you can override it with your own base path by using Zend_Controller_Request_Http and calling the setBaseUrl() method (see Base URL and Subdirectories):

$request->setBaseUrl('/~user/application-root/');

Global Parameters

You can set global parameters in a router which are automatically supplied to a route when assembling through setGlobalParam(). If a global parameter is set but also given to the assemble method directly, the user parameter overrides the global parameter. You can set a global parameter this way:

$router->setGlobalParam('lang', 'en');

Route Types

Zend_Controller_Router_Route

Zend_Controller_Router_Route is the standard framework route. It combines ease of use with flexible route definition. Each route consists primarily of URL mapping (of static and dynamic parts (variables)) and may be initialized with defaults as well as with variable requirements.

Let's imagine our fictional application will need some informational page about the content authors. We want to be able to point our web browsers to http://domain.com/author/martel to see the information about this "martel" guy. And the route for such functionality could look like:

$route = new Zend_Controller_Router_Route(
    'author/:username',
    array(
        'controller' => 'profile',
        'action'     => 'userinfo'
    )
);

$router->addRoute('user', $route);

The first parameter in the Zend_Controller_Router_Route constructor is a route definition that will be matched to a URL. Route definitions consist of static and dynamic parts separated by the slash ('/') character. Static parts are just simple text: author. Dynamic parts, called variables, are marked by prepending a colon to the variable name: :username.

Note: Character Usage

The current implementation allows you to use any character (except a slash) as a variable identifier, but it is strongly recommended that one uses only characters that are valid for PHP variable identifiers. Future implementations may alter this behaviour, which could result in hidden bugs in your code.

This example route should be matched when you point your browser to http://domain.com/author/martel, in which case all its variables will be injected to the Zend_Controller_Request object and will be accessible in your ProfileController. Variables returned by this example may be represented as an array of the following key and value pairs:

$values = array(
    'username'   => 'martel',
    'controller' => 'profile',
    'action'     => 'userinfo'
);

Later on, Zend_Controller_Dispatcher_Standard should invoke the userinfoAction() method of your ProfileController class (in the default module) based on these values. There you will be able to access all variables by means of the Zend_Controller_Action::_getParam() or Zend_Controller_Request::getParam() methods:

public function userinfoAction()
{
    $request = $this->getRequest();
    $username = $request->getParam('username');

    $username = $this->_getParam('username');
}

Route definition can contain one more special character - a wildcard - represented by '*' symbol. It is used to gather parameters similarly to the default Module route (var => value pairs defined in the URI). The following route more-or-less mimics the Module route behavior:

$route = new Zend_Controller_Router_Route(
    ':module/:controller/:action/*',
    array('module' => 'default')
);
$router->addRoute('default', $route);

Variable Defaults

Every variable in the route can have a default and this is what the second parameter of the Zend_Controller_Router_Route constructor is used for. This parameter is an array with keys representing variable names and with values as desired defaults:

$route = new Zend_Controller_Router_Route(
    'archive/:year',
    array('year' => 2006)
);
$router->addRoute('archive', $route);

The above route will match URLs like http://domain.com/archive/2005 and http://example.com/archive. In the latter case the variable year will have an initial default value of 2006.

This example will result in injecting a year variable to the request object. Since no routing information is present (no controller and action parameters are defined), the application will be dispatched to the default controller and action method (which are both defined in Zend_Controller_Dispatcher_Abstract). To make it more usable, you have to provide a valid controller and a valid action as the route's defaults:

$route = new Zend_Controller_Router_Route(
    'archive/:year',
    array(
        'year'       => 2006,
        'controller' => 'archive',
        'action'     => 'show'
    )
);
$router->addRoute('archive', $route);

This route will then result in dispatching to the method showAction() of the class ArchiveController.

Variable Requirements

One can add a third parameter to the Zend_Controller_Router_Route constructor where variable requirements may be set. These are defined as parts of a regular expression:

$route = new Zend_Controller_Router_Route(
    'archive/:year',
    array(
        'year'       => 2006,
        'controller' => 'archive',
        'action'     => 'show'
    ),
    array('year' => '\d+')
);
$router->addRoute('archive', $route);

With a route defined like above, the router will match it only when the year variable will contain numeric data, eg. http://domain.com/archive/2345. A URL like http://example.com/archive/test will not be matched and control will be passed to the next route in the chain instead.

Translated segments

The standard route supports translated segments. To use this feature, you have to define at least a translator (an instance of Zend_Translate) via one of the following ways:

  • Put it into the registry with the key Zend_Translate.

  • Set it via the static method Zend_Controller_Router_Route::setDefaultTranslator().

  • Pass it as fourth parameter to the constructor.

By default, the locale specified in the Zend_Translate instance will be used. To override it, you set it (an instance of Zend_Locale or a locale string) in one of the following ways:

  • Put it into the registry with the key Zend_Locale.

  • Set it via the static method Zend_Controller_Router_Route::setDefaultLocale().

  • Pass it as fifth parameter to the constructor.

  • Pass it as @locale parameter to the assemble method.

Translated segments are separated into two parts. Fixed segments are prefixed by a single @-sign, and will be translated to the current locale when assembling and reverted to the message ID when matching again. Dynamic segments are prefixed by :@. When assembling, the given parameter will be translated and inserted into the parameter position. When matching, the translated parameter from the URL will be reverted to the message ID again.

Note: Message IDs and separate language file

Occasionally a message ID which you want to use in one of your routes is already used in a view script or somewhere else. To have full control over safe URLs, you should use a separate language file for the messages used in the route.

The following is the simplest way to prepare the standard route for translated segment usage:

// Prepare the translator
$translator = new Zend_Translate(
    array(
        'adapter' => 'array',
        'content' => array(),
        'locale'  => 'en'
    )
);
$translator->addTranslation(
    array(
        'content' =>
            array(
                'archive' => 'archiv',
                'year'    => 'jahr',
                'month'   => 'monat',
                'index'   => 'uebersicht'
            ),
        'locale'  => 'de'
    )
);

// Set the current locale for the translator
$translator->setLocale('en');

// Set it as default translator for routes
Zend_Controller_Router_Route::setDefaultTranslator($translator);

This example demonstrates the usage of static segments:

// Create the route
$route = new Zend_Controller_Router_Route(
    '@archive',
    array(
        'controller' => 'archive',
        'action'     => 'index'
    )
);
$router->addRoute('archive', $route);

// Assemble the URL in default locale: archive
$route->assemble(array());

// Assemble the URL in german: archiv
$route->assemble(array());

You can use the dynamic segments to create a module-route like translated version:

// Create the route
$route = new Zend_Controller_Router_Route(
    ':@controller/:@action/*',
    array(
        'controller' => 'index',
        'action'     => 'index'
    )
);
$router->addRoute('archive', $route);

// Assemble the URL in default locale: archive/index/foo/bar
$route->assemble(array('controller' => 'archive', 'foo' => 'bar'));

// Assemble the URL in german: archiv/uebersicht/foo/bar
$route->assemble(array('controller' => 'archive', 'foo' => 'bar'));

You can also mix static and dynamic segments:

// Create the route
$route = new Zend_Controller_Router_Route(
    '@archive/:@mode/:value',
    array(
        'mode'       => 'year'
        'value'      => 2005,
        'controller' => 'archive',
        'action'     => 'show'
    ),
    array('mode'  => '(month|year)'
          'value' => '\d+')
);
$router->addRoute('archive', $route);

// Assemble the URL in default locale: archive/month/5
$route->assemble(array('mode' => 'month', 'value' => '5'));

// Assemble the URL in german: archiv/monat/5
$route->assemble(array('mode' => 'month', 'value' => '5', '@locale' => 'de'));

Zend_Controller_Router_Route_Static

The examples above all use dynamic routes -- routes that contain patterns to match against. Sometimes, however, a particular route is set in stone, and firing up the regular expression engine would be an overkill. The answer to this situation is to use static routes:

$route = new Zend_Controller_Router_Route_Static(
    'login',
    array('controller' => 'auth', 'action' => 'login')
);
$router->addRoute('login', $route);

Above route will match a URL of http://domain.com/login, and dispatch to AuthController::loginAction().

Note: Warning: Static Routes must Contain Sane Defaults

Since a static route does not pass any part of the URL to the request object as parameters, you must pass all parameters necessary for dispatching a request as defaults to the route. Omitting the "controller" or "action" default values will have unexpected results, and will likely result in the request being undispatchable.

As a rule of thumb, always provide each of the following default values:

  • controller

  • action

  • module (if not default)

Optionally, you can also pass the "useDefaultControllerAlways" parameter to the front controller during bootstrapping:

$front->setParam('useDefaultControllerAlways', true);

However, this is considered a workaround; it is always better to explicitly define sane defaults.

Zend_Controller_Router_Route_Regex

In addition to the default and static route types, a Regular Expression route type is available. This route offers more power and flexibility over the others, but at a slight cost of complexity. At the same time, it should be faster than the standard Route.

Like the standard route, this route has to be initialized with a route definition and some defaults. Let's create an archive route as an example, similar to the previously defined one, only using the Regex route this time:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array(
        'controller' => 'archive',
        'action'     => 'show'
    )
);
$router->addRoute('archive', $route);

Every defined regex subpattern will be injected to the request object. With our above example, after successful matching http://domain.com/archive/2006, the resulting value array may look like:

$values = array(
    1            => '2006',
    'controller' => 'archive',
    'action'     => 'show'
);

Note:

Leading and trailing slashes are trimmed from the URL in the Router prior to a match. As a result, matching the URL http://domain.com/foo/bar/, would involve a regex of foo/bar, and not /foo/bar.

Note:

Line start and line end anchors ('^' and '$', respectively) are automatically pre- and appended to all expressions. Thus, you should not use these in your regular expressions, and you should match the entire string.

Note:

This route class uses the '#' character for a delimiter. This means that you will need to escape hash characters ('#') but not forward slashes ('/') in your route definitions. Since the '#' character (named anchor) is rarely passed to the webserver, you will rarely need to use that character in your regex.

You can get the contents of the defined subpatterns the usual way:

public function showAction()
{
    $request = $this->getRequest();
    $year    = $request->getParam(1); // $year = '2006';
}

Note:

Notice the key is an integer (1) instead of a string ('1').

This route will not yet work exactly the same as its standard route counterpart since the default for 'year' is not yet set. And what may not yet be evident is that we will have a problem with a trailing slash even if we declare a default for the year and make the subpattern optional. The solution is to make the whole year part optional along with the slash but catch only the numeric part:

$route = new Zend_Controller_Router_Route_Regex(
    'archive(?:/(\d+))?',
    array(
        1            => '2006',
        'controller' => 'archive',
        'action'     => 'show'
    )
);
$router->addRoute('archive', $route);

Now let's get to the problem you have probably noticed on your own by now. Using integer based keys for parameters is not an easily manageable solution and may be potentially problematic in the long run. And that's where the third parameter comes in. This parameter is an associative array that represents a map of regex subpatterns to parameter named keys. Let's work on our easier example:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array(
        'controller' => 'archive',
        'action' => 'show'
    ),
    array(
        1 => 'year'
    )
);
$router->addRoute('archive', $route);

This will result in following values injected into Request:

$values = array(
    'year'       => '2006',
    'controller' => 'archive',
    'action'     => 'show'
);

The map may be defined in either direction to make it work in any environment. Keys may contain variable names or subpattern indexes:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array( ... ),
    array(1 => 'year')
);

// OR

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array( ... ),
    array('year' => 1)
);

Note:

Subpattern keys have to be represented by integers.

Notice that the numeric index in Request values is now gone and a named variable is shown in its place. Of course you can mix numeric and named variables if you wish:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)/page/(\d+)',
    array( ... ),
    array('year' => 1)
);

Which will result in mixed values available in the Request. As an example, the URL http://domain.com/archive/2006/page/10 will result in following values:

$values = array(
    'year'       => '2006',
    2            => 10,
    'controller' => 'archive',
    'action'     => 'show'
);

Since regex patterns are not easily reversed, you will need to prepare a reverse URL if you wish to use a URL helper or even an assemble method of this class. This reversed path is represented by a string parsable by sprintf() and is defined as a fourth construct parameter:

$route = new Zend_Controller_Router_Route_Regex(
    'archive/(\d+)',
    array( ... ),
    array('year' => 1),
    'archive/%s'
);

All of this is something which was already possible by the means of a standard route object, so where's the benefit in using the Regex route, you ask? Primarily, it allows you to describe any type of URL without any restrictions. Imagine you have a blog and wish to create URLs like: http://domain.com/blog/archive/01-Using_the_Regex_Router.html, and have it decompose the last path element, 01-Using_the_Regex_Router.html, into an article ID and article title or description; this is not possible with the standard route. With the Regex route, you can do something like the following solution:

$route = new Zend_Controller_Router_Route_Regex(
    'blog/archive/(\d+)-(.+)\.html',
    array(
        'controller' => 'blog',
        'action'     => 'view'
    ),
    array(
        1 => 'id',
        2 => 'description'
    ),
    'blog/archive/%d-%s.html'
);
$router->addRoute('blogArchive', $route);

As you can see, this adds a tremendous amount of flexibility over the standard route.

Zend_Controller_Router_Route_Hostname

Zend_Controller_Router_Route_Hostname is the hostname route of the framework. It works similar to the standard route, but it works on the with the hostname of the called URL instead with the path.

Let's use the example from the standard route and see how it would look like in a hostname based way. Instead of calling the user via a path, we'd want to have a user to be able to call http://martel.users.example.com to see the information about the user "martel":

$hostnameRoute = new Zend_Controller_Router_Route_Hostname(
    ':username.users.example.com',
    array(
        'controller' => 'profile',
        'action'     => 'userinfo'
    )
);

$plainPathRoute = new Zend_Controller_Router_Route_Static('');

$router->addRoute('user', $hostnameRoute->chain($plainPathRoute));

The first parameter in the Zend_Controller_Router_Route_Hostname constructor is a route definition that will be matched to a hostname. Route definitions consist of static and dynamic parts separated by the dot ('.') character. Dynamic parts, called variables, are marked by prepending a colon to the variable name: :username. Static parts are just simple text: user.

Hostname routes can, but never should be used as is. The reason behind that is, that a hostname route alone would match any path. So what you have to do is to chain a path route to the hostname route. This is done like in the example by calling $hostnameRoute->chain($pathRoute);. By doing this, $hostnameRoute isn't modified, but a new route (Zend_Controller_Router_Route_Chain) is returned, which can then be given to the router.

Zend_Controller_Router_Route_Chain

Zend_Controller_Router_Route_Chain is a route which allows to chain multiple routes together. This allows you to chain hostname-routes and path routes, or multiple path routes for example. Chaining can be done either programatically or within a configuration file.

Note: Parameter Priority

When chaining routes together, the parameters of the outer route have a higher priority than the parameters of the inner route. Thus if you define a controller in the outer and in the inner route, the controller of the outer route will be selected.

When chaining programatically, there are two ways to achieve this. The first one is to create a new Zend_Controller_Router_Route_Chain instance and then calling the chain() method multiple times with all routes which should be chained together. The other way is to take the first route, e.g. a hostname route, and calling the chain() method on it with the route which should be appended to it. This will not modify the hostname route, but return a new instance of Zend_Controller_Router_Route_Chain, which then has both routes chained together:

// Create two routes
$hostnameRoute = new Zend_Controller_Router_Route_Hostname(...);
$pathRoute     = new Zend_Controller_Router_Route(...);

// First way, chain them via the chain route
$chainedRoute = new Zend_Controller_Router_Route_Chain();
$chainedRoute->chain($hostnameRoute)
             ->chain($pathRoute);

// Second way, chain them directly
$chainedRoute = $hostnameRoute->chain($pathRoute);

When chaining routes together, their separator is a slash by default. There may be cases when you want to have a different separator:

// Create two routes
$firstRoute  = new Zend_Controller_Router_Route('foo');
$secondRoute = new Zend_Controller_Router_Route('bar');

// Chain them together with a different separator
$chainedRoute = $firstRoute->chain($secondRoute, '-');

// Assemble the route: "foo-bar"
echo $chainedRoute->assemble();

Chain Routes via Zend_Config

To chain routes together in a config file, there are additional parameters for the configuration of those. The simpler approach is to use the chains parameters. This one is simply a list of routes, which will be chained with the parent route. Neither the parent- nor the child-route will be added directly to the router but only the resulting chained route. The name of the chained route in the router will be the parent route name and the child route name concatenated with a dash (-) by default. A simple config in XML would look like this:


    
        www.example.com
        
            
                :language
                
                
                    
                        
                        
                    
                    
                        imprint
                        
                    
                
            
        
    
    
        users.example.com
        
            
                :username
                
            
        
    
    
        misc
    

This will result in the three routes www-language-index, www-language-imprint and users-language-profile which will only match based on the hostname and the route misc, which will match with any hostname.

The alternative way of creating a chained route is via the chain parameter, which can only be used with the chain-route type directly, and also just works in the root level:


    
        www.example.com
    
    
        :language
        
    
    
        
        
    
    
        imprint
        
    

    
        www, language, index
    
    
        www, language, imprint
    

You can also give the chain parameter as array instead of separating the routes with a comma:


    
        www
        language
        index
    
    
        www
        language
        imprint
    

When you configure chain routes with Zend_Config and want the chain name separator to be different from a dash, you need to specify this separator separately:

$config = new Zend_Config(array(
    'chainName' => array(
        'type'   => 'Zend_Controller_Router_Route_Static',
        'route'  => 'foo',
        'chains' => array(
            'subRouteName' => array(
                'type'     => 'Zend_Controller_Router_Route_Static',
                'route'    => 'bar',
                'defaults' => array(
                    'module'      => 'module',
                     'controller' => 'controller',
                     'action'     => 'action'
                )
            )
        )
    )
));

// Set separator before adding config
$router->setChainNameSeparator('_separator_')

// Add config
$router->addConfig($config);

// The name of our route now is: chainName_separator_subRouteName
echo $this->_router->assemble(array(), 'chainName_separator_subRouteName');

// The proof: it echoes /foo/bar

Zend_Rest_Route

The Zend_Rest component contains a RESTful route for Zend_Controller_Router_Rewrite. This route offers a standardized routing scheme that routes requests by translating the HTTP method and the URI to a module, controller, and action. The table below provides an overview of how request methods and URI's are routed.

Zend_Rest_Route Behavior
Method URI Module_Controller::action
GET /product/ratings/ Product_RatingsController::indexAction()
GET /product/ratings/:id Product_RatingsController::getAction()
POST /product/ratings Product_RatingsController::postAction()
PUT /product/ratings/:id Product_RatingsController::putAction()
DELETE /product/ratings/:id Product_RatingsController::deleteAction()
POST /product/ratings/:id?_method=PUT Product_RatingsController::putAction()
POST /product/ratings/:id?_method=DELETE Product_RatingsController::deleteAction()

Zend_Rest_Route Usage

To enable Zend_Rest_Route for an entire application, construct it with no config params and add it as the default route on the front controller:

$front     = Zend_Controller_Front::getInstance();
$restRoute = new Zend_Rest_Route($front);
$front->getRouter()->addRoute('default', $restRoute);

Note:

If Zend_Rest_Route cannot match a valid module, controller, or action, it will return FALSE and the router will attempt to match using the next route in the router.

To enable Zend_Rest_Route for specific modules, construct it with an array of module names as the 3rd constructor argument:

$front     = Zend_Controller_Front::getInstance();
$restRoute = new Zend_Rest_Route($front, array(), array('product'));
$front->getRouter()->addRoute('rest', $restRoute);

To enable Zend_Rest_Route for specific controllers, add an array of controller names as the value of each module array element.

$front     = Zend_Controller_Front::getInstance();
$restRoute = new Zend_Rest_Route($front, array(), array(
    'product' => array('ratings')
));
$front->getRouter()->addRoute('rest', $restRoute);

Zend_Rest_Route with Zend_Config_Ini

To use Zend_Rest_Route from an INI config file, use a route type parameter and set the config options:

routes.rest.type = Zend_Rest_Route
routes.rest.defaults.controller = object
routes.rest.mod = project,user

The 'type' option designates the RESTful routing config type. The 'defaults' option is used to specify custom default module, controller, and/or actions for the route. All other options in the config group are treated as RESTful module names, and their values are RESTful controller names. The example config defines Mod_ProjectController and Mod_UserController as RESTful controllers.

Then use the addConfig() method of the Rewrite router object:

$config = new Zend_Config_Ini('path/to/routes.ini');
$router = new Zend_Controller_Router_Rewrite();
$router->addConfig($config, 'routes');

Zend_Rest_Controller

To help or guide development of Controllers for use with Zend_Rest_Route, extend your Controllers from Zend_Rest_Controller. Zend_Rest_Controller defines the 5 most-commonly needed operations for RESTful resources in the form of abstract action methods.

  • indexAction() - Should retrieve an index of resources and assign it to view.

  • getAction() - Should retrieve a single resource identified by URI and assign it to view.

  • postAction() - Should accept a new single resource and persist its state.

  • putAction() - Should accept a single resource idenitifed by URI and persist its state.

  • deleteAction() - Should delete a single resource identified by URI.

Using Zend_Config with the RewriteRouter

Sometimes it is more convenient to update a configuration file with new routes than to change the code. This is possible via the addConfig() method. Basically, you create a Zend_Config-compatible configuration, and in your code read it in and pass it to the RewriteRouter.

As an example, consider the following INI file:

[production]
routes.archive.route = "archive/:year/*"
routes.archive.defaults.controller = archive
routes.archive.defaults.action = show
routes.archive.defaults.year = 2000
routes.archive.reqs.year = "\d+"

routes.news.type = "Zend_Controller_Router_Route_Static"
routes.news.route = "news"
routes.news.defaults.controller = "news"
routes.news.defaults.action = "list"

routes.archive.type = "Zend_Controller_Router_Route_Regex"
routes.archive.route = "archive/(\d+)"
routes.archive.defaults.controller = "archive"
routes.archive.defaults.action = "show"
routes.archive.map.1 = "year"
; OR: routes.archive.map.year = 1

The above INI file can then be read into a Zend_Config object as follows:

$config = new Zend_Config_Ini('/path/to/config.ini', 'production');
$router = new Zend_Controller_Router_Rewrite();
$router->addConfig($config, 'routes');

In the above example, we tell the router to use the 'routes' section of the INI file to use for its routes. Each first-level key under that section will be used to define a route name; the above example defines the routes 'archive' and 'news'. Each route then requires, at minimum, a 'route' entry and one or more 'defaults' entries; optionally one or more 'reqs' (short for 'required') may be provided. All told, these correspond to the three arguments provided to a Zend_Controller_Router_Route_Interface object. An option key, 'type', can be used to specify the route class type to use for that particular route; by default, it uses Zend_Controller_Router_Route. In the example above, the 'news' route is defined to use Zend_Controller_Router_Route_Static.

Subclassing the Router

The standard rewrite router should provide most functionality you may need; most often, you will only need to create a new route type in order to provide new or modified functionality over the provided routes.

That said, you may at some point find yourself wanting to use a different routing paradigm. The interface Zend_Controller_Router_Interface provides the minimal information required to create a router, and consists of a single method.

interface Zend_Controller_Router_Interface
{
  /**
   * @param  Zend_Controller_Request_Abstract $request
   * @throws Zend_Controller_Router_Exception
   * @return Zend_Controller_Request_Abstract
   */
  public function route(Zend_Controller_Request_Abstract $request);
}

Routing only occurs once: when the request is first received into the system. The purpose of the router is to determine the controller, action, and optional parameters based on the request environment, and then set them in the request. The request object is then passed to the dispatcher. If it is not possible to map a route to a dispatch token, the router should do nothing to the request object.

Previous Next
Introduction to Zend Framework
Overview
Installation
Learning Zend Framework
Zend Framework Quick Start
Zend Framework & MVC Introduction
Create Your Project
Create A Layout
Create a Model and Database Table
Create A Form
Congratulations!
Autoloading in Zend Framework
Introduction
Goals and Design
Basic Autoloader Usage
Resource Autoloading
Conclusion
Plugins in Zend Framework
Introduction
Using Plugins
Conclusion
Getting Started with Zend_Layout
Introduction
Using Zend_Layout
Zend_Layout: Conclusions
Getting Started Zend_View Placeholders
Introduction
Basic Placeholder Usage
Standard Placeholders
View Placeholders: Conclusion
Understanding and Using Zend Form Decorators
Introduction
Decorator Basics
Layering Decorators
Rendering Individual Decorators
Creating and Rendering Composite Elements
Conclusion
Getting Started with Zend_Session, Zend_Auth, and Zend_Acl
Building Multi-User Applications With Zend Framework
Managing User Sessions In ZF
Authenticating Users in Zend Framework
Building an Authorization System in Zend Framework
Getting Started with Zend_Search_Lucene
Zend_Search_Lucene Introduction
Lucene Index Structure
Index Opening and Creation
Indexing
Searching
Supported queries
Search result pagination
Getting Started with Zend_Paginator
Introduction
Simple Examples
Pagination Control and ScrollingStyles
Putting it all Together
Zend Framework Reference
Zend_Acl
Introduction
Refining Access Controls
Advanced Usage
Zend_Amf
Introduction
Zend_Amf_Server
Zend_Application
Introduction
Zend_Application Quick Start
Theory of Operation
Examples
Core Functionality
Available Resource Plugins
Zend_Auth
Introduction
Database Table Authentication
Digest Authentication
HTTP Authentication Adapter
LDAP Authentication
Open ID Authentication
Zend_Barcode
Introduction
Barcode creation using Zend_Barcode class
Zend_Barcode Objects
Zend_Barcode Renderers
Zend_Cache
Introduction
The Theory of Caching
Zend_Cache Frontends
Zend_Cache Backends
The Cache Manager
Zend_Captcha
Introduction
Captcha Operation
CAPTCHA Adapters
SimpleCloud API: Zend_Cloud
Document Service Introduction
Queue Service Introduction
StorageService Introduction
Zend_CodeGenerator
Introduction
Zend_CodeGenerator Examples
Zend_CodeGenerator Reference
Zend_Config
Introduction
Theory of Operation
Zend_Config_Ini
Zend_Config_Json
Zend_Config_Xml
Zend_Config_Yaml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
Introduction
Declaring Getopt Rules
Fetching Options and Arguments
Configuring Zend_Console_Getopt
Zend_Controller
Zend_Controller Quick Start
Zend_Controller Basics
The Front Controller
The Request Object
The Standard Router
The Dispatcher
Action Controllers
Action Helpers
The Response Object
Plugins
Using a Conventional Modular Directory Structure
MVC Exceptions
Zend_Currency
Introduction to Zend_Currency
Using Zend_Currency
Options for currencies
What makes a currency?
Where is the currency?
How does the currency look like?
How much is my currency?
Calculating with currencies
Exchanging currencies
Additional informations on Zend_Currency
Zend_Date
Introduction
Theory of Operation
Basic Methods
Zend_Date API Overview
Creation of Dates
Constants for General Date Functions
Working Examples
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
Zend_Db_Table Relationships
Zend_Db_Table_Definition
Zend_Debug
Dumping Variables
Zend_Dojo
Introduction
Zend_Dojo_Data: dojo.data Envelopes
Dojo View Helpers
Dojo Form Elements and Decorators
Zend_Dojo build layer support
Zend_Dom
Introduction
Zend_Dom_Query
Zend_Exception
Using Exceptions
Basic usage
Previous Exceptions
Zend_Feed
Introduction
Importing Feeds
Retrieving Feeds from Web Pages
Consuming an RSS Feed
Consuming an Atom Feed
Consuming a Single Atom Entry
Modifying Feed and Entry structures
Custom Feed and Entry Classes
Zend_Feed_Reader
Zend_Feed_Writer
Zend_Feed_Pubsubhubbub
Zend_File
Zend_File_Transfer
Validators for Zend_File_Transfer
Filters for Zend_File_Transfer
Zend_Filter
Introduction
Standard Filter Classes
Filter Chains
Writing Filters
Zend_Filter_Input
Zend_Filter_Inflector
Zend_Form
Zend_Form
Zend_Form Quick Start
Creating Form Elements Using Zend_Form_Element
Creating Forms Using Zend_Form
Creating Custom Form Markup Using Zend_Form_Decorator
Standard Form Elements Shipped With Zend Framework
Standard Form Decorators Shipped With Zend Framework
Internationalization of Zend_Form
Advanced Zend_Form Usage
Zend_Gdata
Introduction
Authenticating with AuthSub
Using the Book Search Data API
Authenticating with ClientLogin
Using Google Calendar
Using Google Documents List Data API
Using Google Health
Using Google Spreadsheets
Using Google Apps Provisioning
Using Google Base
Using Picasa Web Albums
Using the YouTube Data API
Catching Gdata Exceptions
Zend_Http
Introduction
Zend_Http_Client - Advanced Usage
Zend_Http_Client - Connection Adapters
Zend_Http_Cookie and Zend_Http_CookieJar
Zend_Http_Response
Zend_Http_UserAgent
The UserAgent Device Interface
The UserAgent Features Adapter
The WURFL UserAgent Features Adapter
The DeviceAtlas UserAgent Features Adapter
The TeraWurfl UserAgent Features Adapter
The UserAgent Storage Interface
The Session UserAgent Storage Adapter
Zend_InfoCard
Introduction
Zend_Json
Introduction
Basic Usage
Advanced Usage of Zend_Json
XML to JSON conversion
Zend_Json_Server - JSON-RPC server
Zend_Layout
Introduction
Zend_Layout Quick Start
Zend_Layout Configuration Options
Zend_Layout Advanced Usage
Zend_Ldap
Introduction
API overview
Usage Scenarios
Tools
Object oriented access to the LDAP tree using Zend_Ldap_Node
Getting information from the LDAP server
Serializing LDAP data to and from LDIF
Zend_Loader
Loading Files and Classes Dynamically
The Autoloader
Resource Autoloaders
Loading Plugins
Zend_Locale
Introduction
Using Zend_Locale
Normalization and Localization
Working with Dates and Times
Supported locales
Zend_Log
Overview
Writers
Formatters
Filters
Using the Factory to Create a Log
Zend_Mail
Introduction
Sending via SMTP
Sending Multiple Mails per SMTP Connection
Using Different Transports
HTML E-Mail
Attachments
Adding Recipients
Controlling the MIME Boundary
Additional Headers
Character Sets
Encoding
SMTP Authentication
Securing SMTP Transport
Reading Mail Messages
Zend_Markup
Introduction
Getting Started With Zend_Markup
Zend_Markup Parsers
Zend_Markup Renderers
Zend_Measure
Introduction
Creation of Measurements
Outputting measurements
Manipulating Measurements
Types of measurements
Zend_Memory
Overview
Memory Manager
Memory Objects
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_Navigation
Introduction
Pages
Containers
Zend_Oauth
Introduction to OAuth
Zend_OpenId
Introduction
Zend_OpenId_Consumer Basics
Zend_OpenId_Provider
Zend_Paginator
Introduction
Usage
Configuration
Advanced usage
Zend_Pdf
Introduction
Creating and Loading PDF Documents
Save Changes to PDF Documents
Working with Pages
Drawing
Interactive Features
Document Info and Metadata
Zend_Pdf module usage example
Zend_ProgressBar
Zend_ProgressBar
Zend_Queue
Introduction
Example usage
Framework
Adapters
Customizing Zend_Queue
Stomp
Zend_Reflection
Introduction
Zend_Reflection Examples
Zend_Reflection Reference
Zend_Registry
Using the Registry
Zend_Rest
Introduction
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
Overview
Building Indexes
Searching an Index
Query Language
Query Construction API
Character Set
Extensibility
Interoperating with Java Lucene
Advanced
Best Practices
Zend_Serializer
Introduction
Zend_Serializer_Adapter
Zend_Server
Introduction
Zend_Server_Reflection
Zend_Service
Introduction
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Amazon_Ec2
Zend_Service_Amazon_Ec2: Instances
Zend_Service_Amazon_Ec2: Windows Instances
Zend_Service_Amazon_Ec2: Reserved Instances
Zend_Service_Amazon_Ec2: CloudWatch Monitoring
Zend_Service_Amazon_Ec2: Amazon Machine Images (AMI)
Zend_Service_Amazon_Ec2: Elastic Block Storage (EBS)
Zend_Service_Amazon_Ec2: Elastic IP Addresses
Zend_Service_Amazon_Ec2: Keypairs
Zend_Service_Amazon_Ec2: Regions and Availability Zones
Zend_Service_Amazon_Ec2: Security Groups
Zend_Service_Amazon_S3
Zend_Service_Amazon_Sqs
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_DeveloperGarden
Zend_Service_Ebay
Zend_Service_Ebay_Finding
Zend_Service_Flickr
Zend_Service_LiveDocx
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_ShortUrl
Zend_Service_Simpy
Zend_Service_SlideShare
Zend_Service_StrikeIron
Zend_Service_StrikeIron: Bundled Services
Zend_Service_StrikeIron: Advanced Uses
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_WindowsAzure
Zend_Service_WindowsAzure_Storage_Blob
Zend_Service_WindowsAzure_Diagnostics_Manager
Zend_Service_WindowsAzure_Storage_Queue
Zend_Service_WindowsAzure_Storage_Table
Zend_Service_Yahoo
Zend_Session
Introduction
Basic Usage
Advanced Usage
Global Session Management
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDL Accessor
AutoDiscovery
Zend_Tag
Introduction
Zend_Tag_Cloud
Zend_Test
Introduction
Zend_Test_PHPUnit
Zend_Test_PHPUnit_Db
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
Introduction
Working with Zend_TimeSync
Zend_Tool
Using Zend_Tool On The Command Line
Extending Zend_Tool
Zend_Tool_Framework
Introduction
Using the CLI Tool
Architecture
Creating Providers to use with Zend_Tool_Framework
Shipped System Providers
Extending and Configuring Zend_Tool_Framework
Zend_Tool_Project
Introduction
Create A Project
Zend_Tool Project Providers
Zend_Tool_Project Internals
Zend_Translate
Introduction
Adapters for Zend_Translate
Using Translation Adapters
Creating source files
Additional features for translation
Plural notations for Translation
Zend_Uri
Zend_Uri
Zend_Validate
Introduction
Standard Validation Classes
Validator Chains
Writing Validators
Validation Messages
Zend_Version
Getting the Zend Framework Version
Zend_View
Introduction
Controller Scripts
View Scripts
View Helpers
Zend_View_Abstract
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
Introduction
Zend_XmlRpc_Client
Zend_XmlRpc_Server
ZendX_Console_Process_Unix
ZendX_Console_Process_Unix
ZendX_JQuery
Introduction
ZendX_JQuery View Helpers
ZendX_JQuery Form Elements and Decorators
Zend Framework Requirements
Introduction
Zend Framework Migration Notes
Zend Framework 1.10
Zend Framework 1.9
Zend Framework 1.8
Zend Framework 1.7
Zend Framework 1.6
Zend Framework 1.5
Zend Framework 1.0
Zend Framework 0.9
Zend Framework 0.8
Zend Framework 0.6
Zend Framework Coding Standard for PHP
Overview
PHP File Formatting
Naming Conventions
Coding Style
Zend Framework Documentation Standard
Overview
Documentation File Formatting
Recommendations
Recommended Project Structure for Zend Framework MVC Applications
Overview
Recommended Project Directory Structure
Module Structure
Rewrite Configuration Guide
Zend Framework Performance Guide
Introduction
Class Loading
Zend_Db Performance
Internationalization (i18n) and Localization (l10n)
View Rendering
Copyright Information