Pull to refresh

Comments 25

Появилось это видео c «Symfony Live Paris 2012». А так же другие интересные доклады.

А пост отличный. Спасибо!
Кстати стоит заметить, в комментах говорят о том, что 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>

Но пост отличный, и перевод хороший, спасибо)
Предпоследнее предложение — это конечно мой имхо
Узнал про NelmioApiDocBundle — за это отдельное спасибо.
«Кого ненавидеть»?
гугл транслейт не смог перевести игру слов :(

«Хейтеочто???» — имхо, было бы лучше.
Я бы вообще оригинал оставил, да и вариация Haters gona HATEOAS мне больше по душе. Хейтеочто точно не лучше.
Ну это ж кривой дословный перевод… Из контекста вообще непонятно почему вдруг разговор идет о ненависти.
Такую игру слов не переведешь, чтобы её оценили тогда уж надо и HATEOAS заодно переводить.

«Хейтечто» уж точно не лучше.

Я бы просто поставил «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`.

Хотя, конечно, это всё вкусовщина… просто интересно было.
Ну просто разве это не логично? Если нужен объект определенного типа, почему нужно проверять на null когда можно проверить является ли этот объект нужного нам типа. Ну в общем вы поняли. Издержки то минимальны.

Да, пожалуй это дело вкуса, хотя как по мне это логично и правильно.
А правила сериализации повлияют на все методы которые извлекают юзера?
Правила сериализации задаются для объекта, который вы возвращаете. А сколько методов возвращают этот объект, возвращают они коллекцию или что-то еще роли не играет. Объект в коллекции или просто в составе какого-то объекта сериализуется одинаково.
вот прочитал еще одну статью по restful api
и никак не могу понять зачем заголовки, 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 клиент, который можно будет использовать везде и всюду как основу, но реального профита мало.
Sign up to leave a comment.

Articles