Symfony: веб-сервис REST для ботов и людей - открытые вопросы - PullRequest
Новая
       3

Symfony: веб-сервис REST для ботов и людей - открытые вопросы

3 голосов
/ 01 февраля 2011

Я добавляю API к приложению Symfony, которое должно действовать как веб-сервис REST. Но есть несколько открытых вопросов.

Разные URI для ботов?

Я часто читаю «предложение» использовать URI, такие как /api/:id/[...], но я думаю, что они не будут соответствовать REST: независимо от того, бот или человек - тот же u nique r Источник: i .

Я спрашиваю, поскольку мое утверждение выше имеет смысл, но я не ожидаю, что все остальные виноваты.

Модификация существующих контроллеров?

Есть несколько причин, по которым мне нужна отдельная логика контроллера для обоих случаев:

  • Нет сессионного входа в случае API-запросов
  • должны быть созданы разные формы Symfony (например, виджеты вообще не требуются.)
  • JSON / XML вместо вывода HTML

Я не хочу изменять существующие контроллеры. Согласно принципу Open-Closed классы должны быть открыты для расширения, но закрыты для изменений, а классы контроллеров уже используются в «производственной» среде.

Моя идея - использовать дополнительное поле заголовка HTTP (например, «X-UseApi»). Маршрутизация должна вызывать различные действия, оценивая ее. Это возможно внутри routing.yml? Как? У вас есть другие идеи?

Аутентификация

Вот как я реализовал бот-аутентификацию: 


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

Но код выглядит как обходной путь для моих глаз. Есть ли лучшие решения для всей проблемы аутентификации REST? SfGuardPlugin / sfDoctrineGuardPlugin не соответствует условиям для таких случаев использования?

Спасибо заранее и ура, елочки

Ответы [ 2 ]

0 голосов
/ 21 февраля 2011

Разные URI для ботов?

Предлагаю не слишком беспокоиться о URI.С ними больше проблем, и если слишком много думать об этом, то это приводит к потере времени.ИМХО, было бы здорово, если бы были стандартизированные соглашения о том, как определять RESTful URI.Вот статья об этом: http://redrata.com/restful-uri-design/.Вы можете видеть, что у каждого способа проектирования вашего Uris есть свои плюсы и минусы.

Но сегодня я бы отверг утверждение, что «api / ...» не соответствует REST.Я бы просто избежал этого.

Контроллер и аутентификация

Наконец, мое решение состояло в том, чтобы реализовать некоторые sfFilters с обязанностями следующим образом:

  • ApiAccessFilter : задает атрибут запроса 'isApiRequest', если X-ApiKey определен как поле заголовка.
  • ApiKeyAuthFilter : идентифицирует пользователя по X-ApiKey, вызывает signIn /переадресация на login-action.
  • SecureApiAccessFilter : проверяет, есть ли у текущего пользователя учетные данные apiWriteAccess, если HTTP-метод POST, PUT или DELETE.

Первый фильтр позволяет мне позвонить $request->getAttribute('isApiRequest') позже в моих действиях.Это похоже на isXmlHttpRequest().Наконец, я пришел к выводу, что мне нужно изменить существующие действия, потому что требования изменились из-за расширения веб-сервиса.

Cheers, fishbone

0 голосов
/ 04 февраля 2011

Мой способ сделать это - использовать sf_format в маршрутах, чтобы различать робота и человека (роботу, вероятно, понадобится использовать XML, тогда как человеку нужен HTML.

Я бы изменил свои контроллеры таким образом, чтобыЯ бы делегировал логику отдельным классам в зависимости от того, какой формат запрашивается (это не должно быть слишком большой работой, и вы получите необходимую гибкость).

Что касается аутентификации - пожалуйста, предоставьте немного больше информации окак вы это делаете сейчас - мне недостаточно этого примера, чтобы получить общее представление о том, как работает ваша реализация.

...