Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
На эту тему David Zuelke еще давал замечательную презентацию на Symfony Live в этом году.
Видео, к сожалению, еще пока нет, нашел только с другой конференции.
Видео, к сожалению, еще пока нет, нашел только с другой конференции.
Кстати стоит заметить, в комментах говорят о том, что 2616 рфц убирает LINK/UNLINK методы. Вообще для линковки как-то логичней PUT/PATCH использовать по-моему. К тому же, можно коллекцию линкованных объектов тоже представлять как ресурсы, так что можно будет делать например DELETE /user/1/friends/5 для разлинковки связи 1-5 между юзерами.
И еще, мне вот не понравилось, что автор при линковке опять же работает с сущностью, а не с коллекцией. Хотя в заголовке Link он указывает в rel саму коллекцию, это все же выглядит как-то странно. Если не уходить от метода LINK, заголовки выглядели бы так:
LINK /user/1/friends
Link: </user/2>
Link: </user/5>
Но пост отличный, и перевод хороший, спасибо)
И еще, мне вот не понравилось, что автор при линковке опять же работает с сущностью, а не с коллекцией. Хотя в заголовке Link он указывает в rel саму коллекцию, это все же выглядит как-то странно. Если не уходить от метода LINK, заголовки выглядели бы так:
LINK /user/1/friends
Link: </user/2>
Link: </user/5>
Но пост отличный, и перевод хороший, спасибо)
Узнал про NelmioApiDocBundle — за это отдельное спасибо.
«Кого ненавидеть»?
гугл транслейт не смог перевести игру слов :(
«Хейтеочто???» — имхо, было бы лучше.
гугл транслейт не смог перевести игру слов :(
«Хейтеочто???» — имхо, было бы лучше.
Я бы вообще оригинал оставил, да и вариация Haters gona HATEOAS мне больше по душе. Хейтеочто точно не лучше.
Спасибо!
Интересно, зачем такая страшная проверка на
null?$user = UserQuery::create()->findPk($id);
if (!$user instanceof User) {
throw new NotFoundHttpException('User not found');
}
А где вы тут проверку на null Нашли? Если убрать первую строку, вы же не будете на 100% уверены что вам вернется User или Null. Логично проверить объект на то, является ли он экземпляром нужного нам класса. Всего на десяток символов больше чем классическая проверка на нул, да только надежнее.
Без рефакторинга у нас есть уверенность, что вернётся либо `User`, либо `null`. Не выполнится это только если товарищи, пишущие Propel сойдут вдруг с ума.
Если дело дойдёт до рефакторинга, можно будет вынести `User` в тип входного параметра и быть уверенным, что у нас либо `User`, либо `null`.
Хотя, конечно, это всё вкусовщина… просто интересно было.
Если дело дойдёт до рефакторинга, можно будет вынести `User` в тип входного параметра и быть уверенным, что у нас либо `User`, либо `null`.
Хотя, конечно, это всё вкусовщина… просто интересно было.
А правила сериализации повлияют на все методы которые извлекают юзера?
вот прочитал еще одну статью по restful api
и никак не могу понять зачем заголовки, post, delete put и более мудреные штуки?
что они дают?
чем плох подход, например, задать единый формат вывода
потом этот массив сериализовать в json/xml и отдавать юзеру например
или
был бы рад, если бы «на пальцах» кратко объяснили изъяны этого подхода и что дают именно http статусы?
и никак не могу понять зачем заголовки, post, delete put и более мудреные штуки?
что они дают?
чем плох подход, например, задать единый формат вывода
$api_res = array(
"result_int" => 0/1,
"err_msg" => "тут текст ошибки, если нет - пусто",
"result_details" => array(/* с любым возвращаемым результатом */)
);
потом этот массив сериализовать в json/xml и отдавать юзеру например
{"result_int":0,"err_msg":"тут текст ошибки, если нет - пусто","result_details":{"user_id_created":23}}
или
<api_result>
<result_int>0</result_int>
<err_msg>тут текст ошибки, если нет - пусто</err_msg>
<result_details>
<user_id_created>23</user_id_created>
</result_details>
</api_result>
был бы рад, если бы «на пальцах» кратко объяснили изъяны этого подхода и что дают именно http статусы?
Использование HTTP статусов делает структуру вашей апишки более обобщенной. Ну тобиш HTTP статусы тут выступают в роли уровня абстракции для ваших методов. Вы лишь имплементите интерфейс. Поидее, это должно сокращать время разработки API сервисов, так как и на клиенте, и на сервере, большая часть компонентов системы может быть использована снова и снова. Коды ошибок позволяют не изобретать свои коды, ну и все в этом духе.
Интересно, а если написать полностью restful-контроллер, его можно будет без подводных камней использовать для рендеринга в браузере? Ну т.е. сделать браузер Resftul API клиентом чтоли :)
Ну как бы многие так делают. Допустим если использовать Backbone то это самое то. Но есть нюансы.
Какие нюансы?
При создании записи апишка должна отдавать ID записи, это можно обойти что бы все было действительно по феншую но обычно в этом нету смысла. Так же Backbone по умолчанию не умеет работать с XML, только с JSON. Можно конечно заставить его работать и с XML но опять же смысла в этом особо нету. Так же элементы управления гипермедиа тоже не будут работать ну и т.д. По сути у вас будет доступен только 2-ой уровень REST по приведенной в посте диаграмме, и то не полностью. Если вы хотите конечно, вы можете все допилить до такого состояния, что выйдет хороший универсальный RESTFull клиент, который можно будет использовать везде и всюду как основу, но реального профита мало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация REST API на Symfony2: правильный путь