REST клиент и сервер на Yii

[nightw0rk]

День добрый, подскажите, мне кажется если ваш контроллер обрабатывает только GET запросы?

[ischerbin]

Приветствую! Обновил статью, написал как происходит роутинг запроса в начале описания серверной части. Добавлю здесь, что нам ничто не мешает делать например POST запрос к адресу вида /api/update&model=users, то есть у нас есть как POST параметры в потоке ввода, так и GET параметры в URL (model=users).

[theRavel]

Почему вы работаете напрямую с $_GET? Почему вы в ошибки валидации в API замешиваете html-теги? Почему у вас один контроллер на все модели? Пользователь API может управлять вообще всеми моделями в приложении? Пользователь API может управлять сущностями, которые ему не принадлежат (например удалить чужого пользователя по id)? Почему у вас код лежит на мейл.ру а не на гитхабе/битбакете?

[ischerbin]

Насчет $_GET есть ли важные отличия от Yii::app()->request, особенно в рамках темы статьи? Я привык так, но если объясните почему это неверно — буду благодарен. Насчет HTML это все взято из примера на wiki (ссылка есть в статье). Переделать на шаблоны несложно, опять же речь в статье о другом. Один контроллер потому, что он и есть API, если пользователи авторизуются — никто не мешает использовать эти данные внутри контроллера для разграничения прав. Это упрощенный случай, начальная заготовка. Насчет mail.ru — будет интересно народу — не проблема опубликовать. На данный момент все в моем локальном mercurial репозитории.

[theRavel]

По крайней мере странно, что post body вы получаете средствами фреймворка, а параметры get из глобальной переменной.

Посмотрел на вики, действительно в примере показаны ошибки вперемешку с html-тегами. Но на мой взгляд, это в корне неверно. Предположим мы пишем REST API для мобильного приложения, они что, будут теги вырезать? Как они сделают переводы сообщений об ошибках?

Насчет разных контроллеров. Я понимаю, что у вас сейчас пример и заготовка. Но когда приложение обрастет функциональностью, добавятся специфичные проверки для конкретных сущностей (одна валидация для пользователей, но другая для постов), то вы получите один большой файл ответственный за всё. Да и управление доступом к сущностям странное. Какая бы сущность не существовала в приложении, я могу передать ее имя в API и иметь доступ к созданию/изменению/удалению/чтению.

Насчет репозитория, я бы посмотрел код, но скачать архив, распаковать, открывать файлики или запускать IDE… ну вы поняли.

[ischerbin]

Насчет разных контроллеров. Я понимаю, что у вас сейчас пример и заготовка. Но когда приложение обрастет функциональностью, добавятся специфичные проверки для конкретных сущностей (одна валидация для пользователей, но другая для постов), то вы получите один большой файл ответственный за всё. Да и управление доступом к сущностям странное. Какая бы сущность не существовала в приложении, я могу передать ее имя в API и иметь доступ к созданию/изменению/удалению/чтению.

Согласен, именно потому привел в статье ссылку на готовое решение restfullyii. Там в числе прочего есть и кастомный роутинг и подкатегории.

Также можно расширить мой пример, передав выбор и загрузку модели в action-ы отдельному компоненту. API контроллер разгрузится, а во внешнем компоненте мы можем городить, что угодно.

[harvester]

Добрый день, спасибо за статью, проблему вычисляемых полей в моделях решил по другому, добавил метод в предка:

public function InsertMetaField($fieldName) {
	$this::model()->getMetaData()->columns = array_merge(
		$this::model()->getMetaData()->columns,
		array($fieldName => array('name' => $fieldName))
	);
}

Собственно вызов:

$modelName::model()->InsertMetaField($name);

[itcoder]

Подход к задаче у вас хороший, но реализация не очень, Было бы хорошо если Вы отрефакторили код, прежде чем вставлять его в статью, половину логики модели можно вынести по поведение, добавить проверки на доступ к моделям и параметрам, создать view для html кода. Тогда и Вам будет код легко поддерживать и нам приятно читать.