This is a branch off of jdrich's recently accepted pull request. Wrote some code to allow for the use of configuration files for Drest rather than annotations in the Doctrine models.

This removes some of the tight coupling in this aspect of the metadata parsing. The goal here is to be able to use drivers other than annotations (specifically yaml) to power Drest. Drivers for Yaml, Json, and PHP will be coming in a later commit.

Hello Your framework looks promising, but I had some trouble getting it to work. Routes with params in them did not work correctly So something like this

 *          @Drest\Route(
 *              name="get_brand",
 *              routePattern="/brands/:id",
 *              routeConditions={"id": "\d+"},
 *              verbs={"GET"}
 *          ),

and using a bootstrap like this

<?php
// bootstrap.php
use Doctrine\ORM\EntityManager;
use Drest\Configuration;
use Drest\Event;

require_once "vendor/autoload.php";

// Create a simple "default" Doctrine ORM configuration for Annotations
$isDevMode = true;

// Create an example doctrine application
$ormConfig = new \Doctrine\ORM\Configuration();
$pathToEntities = array(__DIR__ . '/src/');
$ORMDriver = $ormConfig->newDefaultAnnotationDriver($pathToEntities, false);
$ormConfig->setMetadataDriverImpl($ORMDriver);

// Other various configuration options..
$ormConfig->setProxyDir(__DIR__ . '/Entities/Proxies');
$ormConfig->setProxyNamespace('Entities\Proxies');
$ormConfig->setAutoGenerateProxyClasses(true);


// the connection configuration
$dbParams = array(
    'driver'   => 'pdo_mysql',
    'user'     => 'foo',
    'password' => 'foo',
    'dbname'   => 'phpapi',
);

$em = EntityManager::create($dbParams, $ormConfig);

$drestConfig = new Configuration();
$drestConfig->setDetectContentOptions(array(
    Configuration::DETECT_CONTENT_HEADER => 'Accept',
    Configuration::DETECT_CONTENT_EXTENSION => true,
    Configuration::DETECT_CONTENT_PARAM => 'format'
));
$drestConfig->setExposureDepth(3);
$drestConfig->setExposeRequestOption(Configuration::EXPOSE_REQUEST_PARAM_GET, 'expose');
$drestConfig->setMetadataCacheImpl(new \Doctrine\Common\Cache\ArrayCache());
$drestConfig->setDebugMode(true);
$drestConfig->addPathsToConfigFiles($pathToEntities);
// Set up event manager
$evm = new Event\Manager();
//$evm->addEventListener(array('preServiceAction', 'postServiceAction', 'preRouting', 'postRouting', 'preDispatch', 'postDispatch'), new MyEvents\MyEvent());
$emr = \Drest\EntityManagerRegistry::getSimpleManagerRegistry($em);
$drestManager = \Drest\Manager::create($emr, $drestConfig, $evm);
echo $drestManager->dispatch();

(so this uses the default HttpFoundation lib, which is installed) a call to /brands/1 would never see the param. Strangely, calling

echo $drestManager->dispatch(null, null, "Brands::get_brand", array('id'=>1));

works

To fix this, I had to add the following line to MappingRouteMetaData.php -> matcher method

$this->route_params = $matcher->getRouteParams();

Bests

Great idea behind this project. I've tried to integrate it with ZF2 and I'm having some problems (I use modules DoctrineModule and DoctrineORMModule) and existing entities.

I've was able to install Drest via composer and that went smooth, and further I was able to add Drest\Resources annotations so that part looks OK. Now I'm having problems with accessing the API via browser, while ZF throws a routing error.

EDIT: I am now trying with a ZF2 module for api/Drest with one controller, which will handle api routing. I'm not sure if this is the right approach but I guess I'll find that out soon. I was actually able to get Drest router to get executed, but it throws an error: "There are no routes configured to match this request path". I'm using dispatcher like this: $drestManager->dispatch($this->getRequest(), new \Zend\Http\PhpEnvironment\Response()) Is there a way for Drest to automatically get parameters from getRequest?

Btw, currently ZF2 router looks like this:

'router' => array(
    'routes' => array(
        'apps' => array(
            'type' => 'Zend\Mvc\Router\Http\Literal',
            'options' => array(
                'route'    => $root_route,
                'defaults' => array(
                    'controller' => 'Api\Controller\Apps',
                    'action'     => 'index',
                ),
            ),
            'may_terminate' => true,
            'child_routes' => array(
                'default' => array(
                    'type'    => 'Segment',
                    'options' => array(
                        'route'    => '/[apps[/][:appId]]',
                        'constraints' => array(
                            'appId'     => '[0-9]+',
                        ),
                        'defaults' => array(
                        ),
                    ),
                ),
            ),
        ),

EDIT2: I was actually able to get this working in ZF2 by adding 3rd and 4th parameter to dispatch function. I was wondering if this approach is OK or is there a better more general way for doing this?

WORKING ZF2 Controller with Drest:

    public function indexAction()
    {
        $id = (int) $this->params()->fromRoute('appId', 0);

        $entityManager = $this->getServiceLocator()->get('doctrine.entitymanager.orm_default');

        $pathToEntities = array(__DIR__ . '/../../../../Application/src/Application/Entity');

        $request = $this->getRequest();

        $drestConfig = new \Drest\Configuration();
        $drestConfig->setDetectContentOptions(array(
            Configuration::DETECT_CONTENT_HEADER => 'Accept',
            Configuration::DETECT_CONTENT_EXTENSION => true,
            Configuration::DETECT_CONTENT_PARAM => 'format'
        ));

        $drestConfig->setExposureDepth(1);
        $drestConfig->setExposeRequestOption(Configuration::EXPOSE_REQUEST_PARAM_GET, 'expose');
        $drestConfig->setMetadataCacheImpl(new \Doctrine\Common\Cache\ArrayCache());   // use a different adapter for production
        $drestConfig->setDebugMode(true);
        $drestConfig->addPathsToConfigFiles($pathToEntities);

        $evm = new Event\Manager();
        //$evm->addEventListener(array('preServiceAction', 'postServiceAction', 'preRouting', 'postRouting', 'preDispatch', 'postDispatch'), new MyEvents\MyEvent());

        $drestManager = \Drest\Manager::create($entityManager, $drestConfig, $evm);

        $test = new \Zend\Http\PhpEnvironment\Response();

        $viewModel =  new ViewModel(array(
            'data'=>$drestManager->dispatch($request, new \Zend\Http\PhpEnvironment\Response(), 'Application\Entity\Apps::get_apps', array('id' => $id)),
        ));

        $viewModel->setTerminal(true);

        return $viewModel;
    }

EDIT3 - POST Request:

I also tried to implement POST functionality with similar dispatcher than above (just didn't pass in array with id), and I didn't have that much luck here. I'm getting an error

    Requests to push data (PUT/POST/PATCH) can only be used on individual elements. Data collections cannot be pushed

stack trace:

    Drest\Manager.php(310): Drest\Query\ExposeFields->configurePushRequest(NULL)
    Manager.php(211): Drest\Manager->handlePushExposureConfiguration(Object(Drest\Mapping\RouteMetaData), Object(DrestCommon\Representation\Json))
    ...

Any idea what I'm doing wrong?

As the subject suggests, it looks like the XML formatter doesn't correctly handle the DateTime object.

Doctrine Column:

/**
 * @var \DateTime
 *
 * @ORM\Column(name="account_created_on", type="datetime", precision=0, scale=0, nullable=false, unique=false)
 */
 private $createdOn;

Warning: DOMDocument::createTextNode() expects parameter 1 to be string, object given in ..\vendor\leedavis81\drest-common\src\DrestCommon\Representation\Xml.php on line 67

Argument 1 passed to DOMNode::appendChild() must be an instance of DOMNode, null given, called in ..\vendor\leedavis81\drest-common\src\DrestCommon\Representation\Xml.php on line 63 and defined in C:\Users\matlab\git\website\vendor\leedavis81\drest-common\src\DrestCommon\Representation\Xml.php on line 67

The annotation driver at line 182 assumes the representations are set in the metadata contrary to what the documentation says. It doesn't appear to fall back on the defaults set in the configuration:

Argument 1 passed to Drest\Mapping\ClassMetaData::addRepresentations() must be of the type array, null given

I assume simply wrapping this in a check to find out if the metadata is set or not and then falling back on default configuration would solve this issue.

All examples in the documentation seem to use annotations for configuring the mapping between entity and REST resource. Are there any alternative options, such as YAML / XML files, like when using Doctrine?

Something like this:

Acme\DemoBundle\Entity\User:
    routes:
        get_users:
            pattern:    /users
            verbs:      [GET]
            collection: true
        get_user:
            pattern:    /user/:id
            verbs:      [GET]
        update_user:
            pattern:    /user/:id
            verbs:      [PUT, PATCH]
            origin:     get_user

The reason for this is that I want to keep the persistance logic seperated from my entities. My entities shouldn't know how they are going to be saved.

Is it possible? If not, I'd like to propose this as a new feature.

I like the look of this project but I would find it really helpful to see an example of how to set it up in the context of a Symfony 2 application. Specifically, how do I register my entities as resources and how does the Symfony router interact with the Drest router?

The orm entity manager is injected into the drest manager object but may be required to determine default behaviours on a number of drest features.

Currently the entity manager is being injected and passed around a number of function calls in ClassMetaData, RouteMetaData and ExposeFields. Implement a cleaner way of allowing access (service locator? dependency injector?)

Routes are grouped for the sake of option requests to return an "Allow" HTTP header with actionable verbs.

Eg OPTIONS /user/1

may return

Allow: GET, PUT, PATCH

Of the available routes in the group the "origin" route (where that resource resides) will be a GET route and will match the pattern {string}/:id. :id is hard coded in to the AnnotationDriver. This should instead be using the primary key(s) declared in the ORM annotations. This can be read from the entity managers metadata.

Note: Origin routes are optional, "unknown" is used in push service actions if one isn't established. They can also be hard set using the "origin" property on a Route object.

Identify shared components required for both server and client and abstract them into their own VCS. (Representations will be one).

The end goal would be to have 3 components:

drest (server) drest-client drest-common

• Ensure the client only generates exceptions of a custom type "Drest\ClientException"

Documentation specifies to register a custom entity against a particular route(s)..

$customAction = new Action\Custom()
$actionRegistry = new Drest\Service\Action\Registry();
$actionRegistry->register(
    $customAction,
    ['Entities\User::get_user']
);

However this is poor as it means constructing every service action per request regardless of whether it's used. It would be far better to allow users to register the required class name

This is a problem as they (currently) have no knowledge of the construction requirements. There are a number of ways this could be be solved.

• Provide a construction mechanism for the route
• Disable the constructor and depend on a defined handle (would require refactoring)