Комментарии 18
Честно говоря, не сильно понимаю именно RESTful API, когда можно принимать на вход, например, JSON-объект, в который можно запихать любые параметры, какие душе угодно. И проблем подобных не возникнет.
Кстати, хотелось бы услышать ваше мнение по поводу нашей реализации
Кстати, хотелось бы услышать ваше мнение по поводу нашей реализации
-4
Немного непонятно что вы хотели сказать первым высказыванием. Его можно трактовать как «зачем заморачиваться, можно сделать так же примерно, как это делается в SOAP».
Ваша реализация — только реализация автодокументации, исходники к слову сомнительного качества. Если вам интересны способы автоматизации в плане API (если у вас по многу пишутся клиент-серверные приложения), то стоит обратить внимание на HATEOAS, на JSON API и т.д.
Ваша реализация — только реализация автодокументации, исходники к слову сомнительного качества. Если вам интересны способы автоматизации в плане API (если у вас по многу пишутся клиент-серверные приложения), то стоит обратить внимание на HATEOAS, на JSON API и т.д.
0
Мой вопрос был не конкретно к вашему решению, мне просто хотелось услышать именно мнение человека, который работает именно с RESTful API, а не с JSON, как мы, в чем преимущества подхода. То есть именно не «зачем заморачиваться», а чем это лучше, а JSON, например, хуже
0
Просто лично для меня передача JSON в качестве GET-параметра, например, выглядит несколько странновато
+1
Я работаю именно с RESTFull API, и немного не понимаю что вы имеете в виду под фразой «а не с JSON, как мы».
По поводу JSON в GET параметрах — да, это странно. Плюсы такого подхода — можно очень просто разбирать такие штуки как фильры, не будет проблем с передачей массивов и т.д. Например:
привычнее видеть в виде
Но запросы такого рода чуть сложнее разбирать на сервере. А так можно просто сделать json_encode и не париться.
Хотя я согласен, это несколько странно и выглядит не очень опрятно.
По поводу JSON в GET параметрах — да, это странно. Плюсы такого подхода — можно очень просто разбирать такие штуки как фильры, не будет проблем с передачей массивов и т.д. Например:
/api/posts?filter={"name":"admin","type":[1,2,3]}
привычнее видеть в виде
/api/posts?filter[name]=admin&filter[type]=1,2,3
Но запросы такого рода чуть сложнее разбирать на сервере. А так можно просто сделать json_encode и не париться.
Хотя я согласен, это несколько странно и выглядит не очень опрятно.
0
Да, я согласен что выглядит это не лучшим образом. Я сам скрепя сердце остановился на этом подходе. Главным аргументом в его пользу было как раз иметь возможность в фильтрах писать условия 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=10
1. Разве при таком подходе не приходится вручную разбираться в каком именно формате пришли данные, чтобы подставить OR или AND?
2. Почему нельзя сделать отдельные методы для получения по тому или иному параметру?
Я просто не сильно знаком именно с RESTful спецификацией, поэтому может мой вопрос и глупым покажется, но мне интересно.
2. Почему нельзя сделать отдельные методы для получения по тому или иному параметру?
Я просто не сильно знаком именно с RESTful спецификацией, поэтому может мой вопрос и глупым покажется, но мне интересно.
0
К тому же на клиенте это выглядит куда понятнее:
Таким образом очень удобно конфигурировать объекты для запросов.
var posts = posts.query(
{
filter:{category:categoryName, published:1},
order:"id ASC",
limit:20
},
function(){...}
);
Таким образом очень удобно конфигурировать объекты для запросов.
0
Видимо вы ошибочно приняли Fesor за автора статьи.
Я не совсем понимаю что значит
Что касается моего выбора в пользу RESTful — то причина как я уже упоминал в том, что на клиенте я использовал AngularJS, и его реализация $resource мне показалась очень удобной. А она как раз требует RESTful API.
Я не совсем понимаю что значит
принимать на вход, например, JSON-объект, в который можно запихать любые параметрыМожет быть глядя на пример станет яснее.
Что касается моего выбора в пользу RESTful — то причина как я уже упоминал в том, что на клиенте я использовал AngularJS, и его реализация $resource мне показалась очень удобной. А она как раз требует RESTful API.
0
Спасибо, что не поленились опубликовать свои наработки! Я вот поленился, хотя реализация схожа с вашей (вплоть до тестирования курлом) :)
0
Yii в качестве API провайдера, мне кажется довольно не оптимальным решением при высокой нагрузке, особенно, если для работы с бд используется AR.
Ведь зачастую нужно для этого подключение к бд, обработка RBAC правил, вывод пользователю. На каждый такой запрос Yii скушает 3.5-4.5Мб памяти.
Ведь зачастую нужно для этого подключение к бд, обработка RBAC правил, вывод пользователю. На каждый такой запрос Yii скушает 3.5-4.5Мб памяти.
+1
Скажите, пожалуйста, в заголовке Content-Range слово items имеет смысловую нагрузку?
0
Это еденицы измерений. Во всех примерах, учитывая специфику этого заголовка, вы можете увидеть bytes в качестве едениц измерения.
0
И еще вопрос в догонку. Если делается запрос GET /users, и, соответственно, в ответе ожидается массив сущностей. Если этот массив пустой, то что ваше API возвращает: 404 или 200 с пустым массивом в теле?
0
Как бы вы реализовали следующий функционал:
— есть API тороговой площадки
— пользователи API — продавцы
— есть сущность «комментарий к заказу», совпадает с REST ресурсом «комментарий к заказу».
— есть сущность «заказ». Ресурс «заказ» = сущность «заказ» + поле comments, содержащее массив комментариев к данному заказу
— при любом изменении данных заказа (статус, время доставки итд) должен быть добавлен комментарий
Продавец хочет изменить поле заказа, для этого необходимо совершить действия с двумя ресурсами: обновить поле заказа и создать новый комментарий.
Варианты как это реализовать в API:
1. Два раздельных REST вызова: PATCH /orders/123 и POST /orders/123/comments. Недостаток — нет гарантии того, что оба вызова будут сделаны.
2. Один RPC вызов POST /order/update, который принимает новое значение поля и текст комментария. Недостаток — уходим в сторону от REST
Сталкивались ли вы с похожей задачей?
— есть API тороговой площадки
— пользователи API — продавцы
— есть сущность «комментарий к заказу», совпадает с REST ресурсом «комментарий к заказу».
— есть сущность «заказ». Ресурс «заказ» = сущность «заказ» + поле comments, содержащее массив комментариев к данному заказу
— при любом изменении данных заказа (статус, время доставки итд) должен быть добавлен комментарий
Продавец хочет изменить поле заказа, для этого необходимо совершить действия с двумя ресурсами: обновить поле заказа и создать новый комментарий.
Варианты как это реализовать в API:
1. Два раздельных REST вызова: PATCH /orders/123 и POST /orders/123/comments. Недостаток — нет гарантии того, что оба вызова будут сделаны.
2. Один RPC вызов POST /order/update, который принимает новое значение поля и текст комментария. Недостаток — уходим в сторону от REST
Сталкивались ли вы с похожей задачей?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RESTful API на Yii framework с RBAC и тестами