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

[Anexroid]

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

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

[Fesor]

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

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

[Anexroid]

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

[Anexroid]

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

[Fesor]

Я работаю именно с 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]

Да, я согласен что выглядит это не лучшим образом. Я сам скрепя сердце остановился на этом подходе. Главным аргументом в его пользу было как раз иметь возможность в фильтрах писать условия 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]

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

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

[goodnickoff]

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

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

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

[Anexroid]

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

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

[goodnickoff]

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

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

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

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

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

[Desher]

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

[x88]

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

[goodnickoff]

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

[aazon]

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

[Fesor]

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

[aazon]

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

[goodnickoff]

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

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

[aazon]

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

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

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