Question

I’m adding an API to a Symfony-application which should act as a REST web-service. But there are a few open issues.

Different URIs for bots?

I often read the "suggestion" to use URIs like /api/:id/[...], but I think they wouldn’t be REST-compliant: No matter whether bot or human – the same unique resource is identified.

I’m asking, since my statement above makes sense, but I don’t expect all the others to be at fault.

Modifying existing controllers?

There are several reasons why I need a separate controller-logic for both cases:

• No session-login in the case of a api-requests
• different Symfony-forms have to be created (For instance, no widgets are required, at all.)
• JSON / XML instead of HTML output

I don’t want to modify existing controllers. According to the Open-Closed Principle, classes should be open for extension but closed for modifications, and the controller classes are already in use in a "production"-environment.

My idea is to use an extra HTTP header-field (e.g. "X-UseApi"). The routing should call different actions by evaluating it. Is this possible inside routing.yml? How? Do you have other ideas?

Authentication

This is how I implemented bot-authentication:

$user = Doctrine_Core::getTable('sfGuardUser')->findOneByUsername($params['user']);
if($user->checkPassword($params['password']))
{
  //...
}

But the code looks like a workaround to my eyes. Are there better solutions for the whole REST authentication issue? Is the sfGuardPlugin / sfDoctrineGuardPlugin not meeting conditions for such use cases?

Thanks in advance and cheers,
fishbone

Answer 1

Different URIs for bots?

I suggest to not worry too much about URIs. There are more problems with them and thinking too much about it just results in losing time. IMHO it would be great if there would be standardized conventions how to define RESTful URIs. Here is an article about it: http://redrata.com/restful-uri-design/ . You can see that every way of designing your uris has its pros and cons.

But today I would reject the statement that ‘api/…’ isn’t REST compliant. I would just avoid it.

Controller and authentication

Finally, my solution was to implement some sfFilters with responsibilities as follows:

• ApiAccessFilter: sets request-attribute ‘isApiRequest’ if X-ApiKey is defined as header field.
• ApiKeyAuthFilter: identifies a user by X-ApiKey, calls signIn / forwards to login-action.
• SecureApiAccessFilter: Checks whether the current user has credential
  ‘apiWriteAccess’, if HTTP-method is POST, PUT or DELETE.

The first filter allows me to call $request->getAttribute('isApiRequest') later in my actions. That’s similar to isXmlHttpRequest(). Finally I came to the conclusion that I have to modify existing actions, because requirements have changed due to the web-service extension.

Cheers, fishbone