goodnickoff 27 мая 2014 в 00:00

RESTful API на Yii framework с RBAC и тестами

19 мин

29K

PHP*Yii*API*

Из песочницы

+15

Комментарии 18

Anexroid 27 мая 2014 в 01:37

Честно говоря, не сильно понимаю именно RESTful API, когда можно принимать на вход, например, JSON-объект, в который можно запихать любые параметры, какие душе угодно. И проблем подобных не возникнет.

Кстати, хотелось бы услышать ваше мнение по поводу нашей реализации

-4

Fesor 27 мая 2014 в 01:48

Немного непонятно что вы хотели сказать первым высказыванием. Его можно трактовать как «зачем заморачиваться, можно сделать так же примерно, как это делается в SOAP».

Ваша реализация — только реализация автодокументации, исходники к слову сомнительного качества. Если вам интересны способы автоматизации в плане API (если у вас по многу пишутся клиент-серверные приложения), то стоит обратить внимание на HATEOAS, на JSON API и т.д.

Anexroid 27 мая 2014 в 01:54

Мой вопрос был не конкретно к вашему решению, мне просто хотелось услышать именно мнение человека, который работает именно с RESTful API, а не с JSON, как мы, в чем преимущества подхода. То есть именно не «зачем заморачиваться», а чем это лучше, а JSON, например, хуже

Anexroid 27 мая 2014 в 02:01

Просто лично для меня передача JSON в качестве GET-параметра, например, выглядит несколько странновато

Fesor 27 мая 2014 в 02:13

Я работаю именно с RESTFull API, и немного не понимаю что вы имеете в виду под фразой «а не с JSON, как мы».

По поводу JSON в GET параметрах — да, это странно. Плюсы такого подхода — можно очень просто разбирать такие штуки как фильры, не будет проблем с передачей массивов и т.д. Например:
/api/posts?filter={"name":"admin","type":[1,2,3]}
привычнее видеть в виде
/api/posts?filter[name]=admin&filter[type]=1,2,3
Но запросы такого рода чуть сложнее разбирать на сервере. А так можно просто сделать json_encode и не париться.

Хотя я согласен, это несколько странно и выглядит не очень опрятно.

goodnickoff 27 мая 2014 в 02:23

Да, я согласен что выглядит это не лучшим образом. Я сам скрепя сердце остановился на этом подходе. Главным аргументом в его пользу было как раз иметь возможность в фильтрах писать условия AND и OR:
/api/posts?filter={"name":"admin","type":1} — name=admin AND type=1
/api/posts?filter={"name":"admin"},{"type":1} — name=admin OR type=1

Anexroid 27 мая 2014 в 04:42

1. Разве при таком подходе не приходится вручную разбираться в каком именно формате пришли данные, чтобы подставить OR или AND?
2. Почему нельзя сделать отдельные методы для получения по тому или иному параметру?

Я просто не сильно знаком именно с RESTful спецификацией, поэтому может мой вопрос и глупым покажется, но мне интересно.

goodnickoff 27 мая 2014 в 02:42

К тому же на клиенте это выглядит куда понятнее:

var posts = posts.query(
    {
        filter:{category:categoryName, published:1},
        order:"id ASC",
        limit:20
    }, 
    function(){...}
);

Таким образом очень удобно конфигурировать объекты для запросов.

Anexroid 27 мая 2014 в 04:43

Ну да, в целом теперь понятно. Просто у меня формат задач несколько иной.

Спасибо за разъяснения

goodnickoff 27 мая 2014 в 02:17

Видимо вы ошибочно приняли Fesor за автора статьи.

Я не совсем понимаю что значит

принимать на вход, например, JSON-объект, в который можно запихать любые параметры

Может быть глядя на пример станет яснее.

Что касается моего выбора в пользу RESTful — то причина как я уже упоминал в том, что на клиенте я использовал AngularJS, и его реализация $resource мне показалась очень удобной. А она как раз требует RESTful API.

Desher 27 мая 2014 в 07:05

Спасибо, что не поленились опубликовать свои наработки! Я вот поленился, хотя реализация схожа с вашей (вплоть до тестирования курлом) :)

x88 27 мая 2014 в 09:27

Yii в качестве API провайдера, мне кажется довольно не оптимальным решением при высокой нагрузке, особенно, если для работы с бд используется AR.
Ведь зачастую нужно для этого подключение к бд, обработка RBAC правил, вывод пользователю. На каждый такой запрос Yii скушает 3.5-4.5Мб памяти.

goodnickoff 27 мая 2014 в 09:46

Да, я упомянул об этом в статье. Но как я уже говорил, проблему можно решить кэшированием запросов. Хотя я и близко не сталкивался с проблемами производительности, используя этот подход.

aazon 30 мая 2014 в 12:56

Скажите, пожалуйста, в заголовке Content-Range слово items имеет смысловую нагрузку?

Fesor 30 мая 2014 в 13:27

Это еденицы измерений. Во всех примерах, учитывая специфику этого заголовка, вы можете увидеть bytes в качестве едениц измерения.

aazon 30 мая 2014 в 13:37

И еще вопрос в догонку. Если делается запрос GET /users, и, соответственно, в ответе ожидается массив сущностей. Если этот массив пустой, то что ваше API возвращает: 404 или 200 с пустым массивом в теле?

goodnickoff 5 июн 2014 в 10:37

Прошу прощения за поздний ответ.

В этом случае в ответе вернется пустой массив ([]) с кодом ответа 200. При желании это поведение можно легко изменить.

aazon 30 июн 2014 в 14:14

Как бы вы реализовали следующий функционал:
— есть API тороговой площадки
— пользователи API — продавцы
— есть сущность «комментарий к заказу», совпадает с REST ресурсом «комментарий к заказу».
— есть сущность «заказ». Ресурс «заказ» = сущность «заказ» + поле comments, содержащее массив комментариев к данному заказу
— при любом изменении данных заказа (статус, время доставки итд) должен быть добавлен комментарий

Продавец хочет изменить поле заказа, для этого необходимо совершить действия с двумя ресурсами: обновить поле заказа и создать новый комментарий.
Варианты как это реализовать в API:
1. Два раздельных REST вызова: PATCH /orders/123 и POST /orders/123/comments. Недостаток — нет гарантии того, что оба вызова будут сделаны.
2. Один RPC вызов POST /order/update, который принимает новое значение поля и текст комментария. Недостаток — уходим в сторону от REST

Сталкивались ли вы с похожей задачей?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время

RESTful API на Yii framework с RBAC и тестами

Комментарии 18

Публикации

Истории