Comments 8
День добрый, подскажите, мне кажется если ваш контроллер обрабатывает только GET запросы?
Приветствую! Обновил статью, написал как происходит роутинг запроса в начале описания серверной части. Добавлю здесь, что нам ничто не мешает делать например POST запрос к адресу вида
/api/update&model=users, то есть у нас есть как POST параметры в потоке ввода, так и GET параметры в URL (model=users).
Почему вы работаете напрямую с $_GET? Почему вы в ошибки валидации в API замешиваете html-теги? Почему у вас один контроллер на все модели? Пользователь API может управлять вообще всеми моделями в приложении? Пользователь API может управлять сущностями, которые ему не принадлежат (например удалить чужого пользователя по id)? Почему у вас код лежит на мейл.ру а не на гитхабе/битбакете?
Насчет $_GET есть ли важные отличия от Yii::app()->request, особенно в рамках темы статьи? Я привык так, но если объясните почему это неверно — буду благодарен. Насчет HTML это все взято из примера на wiki (ссылка есть в статье). Переделать на шаблоны несложно, опять же речь в статье о другом. Один контроллер потому, что он и есть API, если пользователи авторизуются — никто не мешает использовать эти данные внутри контроллера для разграничения прав. Это упрощенный случай, начальная заготовка. Насчет mail.ru — будет интересно народу — не проблема опубликовать. На данный момент все в моем локальном mercurial репозитории.
По крайней мере странно, что post body вы получаете средствами фреймворка, а параметры get из глобальной переменной.
Посмотрел на вики, действительно в примере показаны ошибки вперемешку с html-тегами. Но на мой взгляд, это в корне неверно. Предположим мы пишем REST API для мобильного приложения, они что, будут теги вырезать? Как они сделают переводы сообщений об ошибках?
Насчет разных контроллеров. Я понимаю, что у вас сейчас пример и заготовка. Но когда приложение обрастет функциональностью, добавятся специфичные проверки для конкретных сущностей (одна валидация для пользователей, но другая для постов), то вы получите один большой файл ответственный за всё. Да и управление доступом к сущностям странное. Какая бы сущность не существовала в приложении, я могу передать ее имя в API и иметь доступ к созданию/изменению/удалению/чтению.
Насчет репозитория, я бы посмотрел код, но скачать архив, распаковать, открывать файлики или запускать IDE… ну вы поняли.
Посмотрел на вики, действительно в примере показаны ошибки вперемешку с html-тегами. Но на мой взгляд, это в корне неверно. Предположим мы пишем REST API для мобильного приложения, они что, будут теги вырезать? Как они сделают переводы сообщений об ошибках?
Насчет разных контроллеров. Я понимаю, что у вас сейчас пример и заготовка. Но когда приложение обрастет функциональностью, добавятся специфичные проверки для конкретных сущностей (одна валидация для пользователей, но другая для постов), то вы получите один большой файл ответственный за всё. Да и управление доступом к сущностям странное. Какая бы сущность не существовала в приложении, я могу передать ее имя в API и иметь доступ к созданию/изменению/удалению/чтению.
Насчет репозитория, я бы посмотрел код, но скачать архив, распаковать, открывать файлики или запускать IDE… ну вы поняли.
Насчет разных контроллеров. Я понимаю, что у вас сейчас пример и заготовка. Но когда приложение обрастет функциональностью, добавятся специфичные проверки для конкретных сущностей (одна валидация для пользователей, но другая для постов), то вы получите один большой файл ответственный за всё. Да и управление доступом к сущностям странное. Какая бы сущность не существовала в приложении, я могу передать ее имя в API и иметь доступ к созданию/изменению/удалению/чтению.
Согласен, именно потому привел в статье ссылку на готовое решение restfullyii. Там в числе прочего есть и кастомный роутинг и подкатегории.
Также можно расширить мой пример, передав выбор и загрузку модели в action-ы отдельному компоненту. API контроллер разгрузится, а во внешнем компоненте мы можем городить, что угодно.
Добрый день, спасибо за статью, проблему вычисляемых полей в моделях решил по другому, добавил метод в предка:
Собственно вызов:
public function InsertMetaField($fieldName) {
$this::model()->getMetaData()->columns = array_merge(
$this::model()->getMetaData()->columns,
array($fieldName => array('name' => $fieldName))
);
}
Собственно вызов:
$modelName::model()->InsertMetaField($name);
Подход к задаче у вас хороший, но реализация не очень, Было бы хорошо если Вы отрефакторили код, прежде чем вставлять его в статью, половину логики модели можно вынести по поведение, добавить проверки на доступ к моделям и параметрам, создать view для html кода. Тогда и Вам будет код легко поддерживать и нам приятно читать.
Sign up to leave a comment.
REST клиент и сервер на Yii