Как стать автором
Обновить

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

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

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

Ваша реализация — только реализация автодокументации, исходники к слову сомнительного качества. Если вам интересны способы автоматизации в плане API (если у вас по многу пишутся клиент-серверные приложения), то стоит обратить внимание на HATEOAS, на JSON API и т.д.
Мой вопрос был не конкретно к вашему решению, мне просто хотелось услышать именно мнение человека, который работает именно с RESTful API, а не с JSON, как мы, в чем преимущества подхода. То есть именно не «зачем заморачиваться», а чем это лучше, а JSON, например, хуже
Просто лично для меня передача JSON в качестве GET-параметра, например, выглядит несколько странновато
Я работаю именно с 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 и не париться.

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

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

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

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

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

Я не совсем понимаю что значит
принимать на вход, например, JSON-объект, в который можно запихать любые параметры
Может быть глядя на пример станет яснее.

Что касается моего выбора в пользу RESTful — то причина как я уже упоминал в том, что на клиенте я использовал AngularJS, и его реализация $resource мне показалась очень удобной. А она как раз требует RESTful API.
Спасибо, что не поленились опубликовать свои наработки! Я вот поленился, хотя реализация схожа с вашей (вплоть до тестирования курлом) :)
Yii в качестве API провайдера, мне кажется довольно не оптимальным решением при высокой нагрузке, особенно, если для работы с бд используется AR.
Ведь зачастую нужно для этого подключение к бд, обработка RBAC правил, вывод пользователю. На каждый такой запрос Yii скушает 3.5-4.5Мб памяти.
Да, я упомянул об этом в статье. Но как я уже говорил, проблему можно решить кэшированием запросов. Хотя я и близко не сталкивался с проблемами производительности, используя этот подход.
Скажите, пожалуйста, в заголовке Content-Range слово items имеет смысловую нагрузку?
Это еденицы измерений. Во всех примерах, учитывая специфику этого заголовка, вы можете увидеть bytes в качестве едениц измерения.
И еще вопрос в догонку. Если делается запрос GET /users, и, соответственно, в ответе ожидается массив сущностей. Если этот массив пустой, то что ваше API возвращает: 404 или 200 с пустым массивом в теле?
Прошу прощения за поздний ответ.

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

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

Сталкивались ли вы с похожей задачей?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.