Ребят, а как так может быть, чтобы я добавлял новый метод, а он переписывал все предыдущие? Это что за фигня?
Тщетно пытаюсь починить запрос на своём сайте
По заголовкам — UTF-8, а на деле — Windows-1251. Вот сука! Хоть бы экранировала свой JSON. Никак не могу понять, где нужно что поменять, чтоб стало хорошо. Долго копался в исходниках, там обработки media=json вообще нет, и самой обработки запроса, того, что мне нужно, нет. Вот есть объекты, и вот они стали кривым JSON, где это недостающее звено посередине. Всё от чего–то наследуется, ищи–свищи, где там какой козёл забрёл в огород Windows-1251 на сайте, который насквозь UTF-8 должен быть по идее. Ну вроде нашёл какой–то левый org.restlet.service.*, который вообще из другого проекта подтянулся по зависимостям и не считается с настройками остального сайта. И вот даже нашёл страничку, из которой понятно стало, каким образом media=json срабатывает. Непонятно, что где поменять, чтоб JSON был на самом деле UTF-8. То ли в web.xml поменять (что?), то ли в движке сайта, где делаются настройки для Restlet, то ли в самом Restlet. Ну и лапша!
По заголовкам — UTF-8, а на деле — Windows-1251. Вот сука! Хоть бы экранировала свой JSON. Никак не могу понять, где нужно что поменять, чтоб стало хорошо. Долго копался в исходниках, там обработки media=json вообще нет, и самой обработки запроса, того, что мне нужно, нет. Вот есть объекты, и вот они стали кривым JSON, где это недостающее звено посередине. Всё от чего–то наследуется, ищи–свищи, где там какой козёл забрёл в огород Windows-1251 на сайте, который насквозь UTF-8 должен быть по идее. Ну вроде нашёл какой–то левый org.restlet.service.*, который вообще из другого проекта подтянулся по зависимостям и не считается с настройками остального сайта. И вот даже нашёл страничку, из которой понятно стало, каким образом media=json срабатывает. Непонятно, что где поменять, чтоб JSON был на самом деле UTF-8. То ли в web.xml поменять (что?), то ли в движке сайта, где делаются настройки для Restlet, то ли в самом Restlet. Ну и лапша!
А раскажите чтоли про проектирование rest интерфейсов, вот например у меня следующее есть
а). мне нужно на один запрос отдать 2 файла, как это делать правильно?
б). если создавать ресурсы, то как ими принято управлять?
в). так же есть следующий кейс, нужно провести операцию над двумя файлами и получить результат. Как это лучше делать 1 post страничка и ждать multipart-form-data оттуда выдёргивать файлы и сразу выдавать результат? Ждать, что пользователь два файла (post/put) и потом вызовет get метод указав пути к файлам?
а). мне нужно на один запрос отдать 2 файла, как это делать правильно?
б). если создавать ресурсы, то как ими принято управлять?
в). так же есть следующий кейс, нужно провести операцию над двумя файлами и получить результат. Как это лучше делать 1 post страничка и ждать multipart-form-data оттуда выдёргивать файлы и сразу выдавать результат? Ждать, что пользователь два файла (post/put) и потом вызовет get метод указав пути к файлам?
Интересно, насколько полезны на практике генерилки REST API с жесткой привязкой к моделям типа flask-restless? Мне почему-то кажется, что такое подходит лишь для простейших случаев, для реальной жизни больше подходит что-то типа django-rest-framework, с разделением на модель-сериализатор-контроллер.
Скорее всего будем использовать в проекте REST. а Как вы относитесь к этому протоколу?
Интересный сервис для создания mock rest сервисов: apiary.io
Коллеги из соседней группы пытаются доказать что единственным правильным методом организации REST API является асинхронный — клиент получает уникальный redirect и должен полить его до получения результата. Я первый раз когда услышал про такое, даже не знал что сказать...
Скажите, а как в REST (некое generic api) полагается синхронизировать данные клиента и сервера? То есть, как следить за тем, что данные поменялись и дергать изменения?
А нафига люди проектируют взаимодействие сервисов на основе soap? Не пороще ли взять обычный REST и не париться? Зачем нужно вводить лишние сущности наподобие wsdl, wcf и т.д.?
Сходить что-ли на выходных на I Games-Expo dynamics-expo.com.ua
Вчера в качестве зевак наблюдали за fly-бордистом на Днепре. Fly-борд — такая штука которая надевается на ноги, затем по шлангу под давлением в него нагнетается вода и она с высокой скоростью вырывается из-под fly-борда. В результате получившейся реактивной тяги fly-бордист парит на водой.
В роликах на ютубе очень эффектно всё это выглядит. А вот перворазник fly-бордист еле удерживался на борде и с трудом поднимался на сколько-нибудь существенную высоту. В результате желание покататься на таком борде у меня опустилось до неопределённого "если бесплатно, то попробовал бы".
В роликах на ютубе очень эффектно всё это выглядит. А вот перворазник fly-бордист еле удерживался на борде и с трудом поднимался на сколько-нибудь существенную высоту. В результате желание покататься на таком борде у меня опустилось до неопределённого "если бесплатно, то попробовал бы".
господа а как в RESTful интерфейсах принято сообщать о неудаче какой-то операции? 4XX статус кодами? Или как-то ещё?
К примеру, у меня есть некий POST запрос на изменение некоего ресурса с MAC подписью. В случае если MAC проверка не прошла я хочу возвращать 403 Forbidden . А в случае если произошла некая ошибка при обновлении в БД ? Есть на этот счёт какие-нить рекомендации?
К примеру, у меня есть некий POST запрос на изменение некоего ресурса с MAC подписью. В случае если MAC проверка не прошла я хочу возвращать 403 Forbidden . А в случае если произошла некая ошибка при обновлении в БД ? Есть на этот счёт какие-нить рекомендации?
Выходы. Хочу за пару месяцев догнать до 10-11. Последний восьмой уже не очень гладко прошёл.
youtube.com
youtube.com
Пресс. Полтинничек. Сразу ровно ещё не получается, приходится после 40 — 45 немного дышать, иначе мотор даёт о себе знать. Как дойду до 60 — 70 раз, буду брать с собой небольшую гантельку, чтобы жизнь мёдом не казалась.
youtube.com
youtube.com
Женщина без Бороды....; )
как правильно в rest модели делаются действия над ресурсом, типа послать ресурсу сообщение.
На horicky.blogspot.com нашёл вот такой кусок: Find all dogs whose master is John. GET /persons/search?q=(name,eqJohn)/dogs — ладно с условием там кривовато (и запятая явно потерялась), но в query string писать /<подобъект> — это нормальная практика? и есть какой-то стандарт на это?
Django REST Framework продолжает показывать себя с хорошей стороны. Из плюсов использования его с Backbone.js могу точно назвать, что он гарантированно поддерживает Backbone.js на уровне PUT/DELETE запросов, по схеме, которая используется в Ruby On Rails (то есть непосредственной передаче по POST запроса с дополнительным параметром _method = "PUT" в случае PUT, или _method = "DELETE" в случае DELETE.
В общем несмотря на то, что эта штука пока развивается, и отстает по возрасту и популярности от Tastypie, она очень даже весьма крута и красива.
В общем несмотря на то, что эта штука пока развивается, и отстает по возрасту и популярности от Tastypie, она очень даже весьма крута и красива.
Все в тегах, все в них, родимых.
pastebin.com
pastebin.com
Жуйк. А вот как считаешь ты, нужны ли в REST вложенные ресурсы, или это правда сильно противоречит идеологии REST? Вот я считаю, что без них никуда, и раз уж REST работает с "состояниями", то состояние может описываться несколькими параметрами к примеру. Если более неформально и приземленно. Возьму пример из нашего приложения. Вот есть марки автомобилей. Есть их модели, и модификации моделей. Получается три уровня: marks -> models -> modifications. То есть вложенность пусть и в три уровня, но она семантически понятна и верна, и таковой останется при организации по данной схеме URL. А если к примеру организовать без вложенности: modifications/[mark_id]/[model_id]/[modification_id] Семантики ноль, краткость не шибко выше, а через GET параметры передавать — не сильно уж тогда это по REST будет.
И собственно почему возник вопрос. Вообще откуда у автора к примеру Tastypie, да и у других подобно мыслящих такие вот идеи? Ну по сути ведь, REST очень схож с реляционной моделью. Те же отношения в определенный момент времени, те же кортежи, а вложенность — это внешние ключи по сути своей. Реляционная модель не запрещает же внешние ключи, и связи между отношениями, так почему REST, так же описывающий "реальное представление мира" должен отказываться от таких средств?
И собственно почему возник вопрос. Вообще откуда у автора к примеру Tastypie, да и у других подобно мыслящих такие вот идеи? Ну по сути ведь, REST очень схож с реляционной моделью. Те же отношения в определенный момент времени, те же кортежи, а вложенность — это внешние ключи по сути своей. Реляционная модель не запрещает же внешние ключи, и связи между отношениями, так почему REST, так же описывающий "реальное представление мира" должен отказываться от таких средств?
Как оказалось, Tastypie, несмотря на всю его красоту, то еще поделие. Автор фреймворка, видите ли отрицательно относится к вложенным ресурсам (а как же без них родимых, ибо 1-2 уровня вложенности не запрещаются ни одним экспертом REST, но очень часто жизненнонеобходимы). В итоге получаем, что чтобы сделать простые GET ресурсы с вложенностью, надо так извращаться над кодом, что этот код становится совершенно не сопровождаем. В итоге отказались от сего поделия, и выбрали более православный, хоть и более молодой Django RESTFramework. Эта умница не только в 20-30 раз кратче делает вложенные ресурсы, причем они по умолчанию поддерживаются без всякого геммороя, но также имеет веб-морду к API — то есть, веб-морда на "поиграться" с API. Причем, он сам понимает, когда ему AJAX подсовывают, а когда стоит страницу для удобного анализа запросов подсунуть клиенту, что очеееень радует. В общем пока нарадоваться не можем, красоте и идеологии сего инструмента. А tastypie забыли как страшный сон, хотя и выглядел он как конфетка.
quora.com на Quora задали вопрос, какое самое RESTful API в интернете. В первом же ответе каким-то боком затесался Amazon S3. Мне так кажется, или у Amazon вроде смесь REST с RPC, ну короче что-то свое )
Ах да, так вот, собственно, решение:
1. Запрос должен идти с заголовком Contrent-Type: application/json (ну, или другим каким-то, в котором возможно слать не тупо ключ-значение, а массив)
2. Если обычный запрос идёт на /api/items/ , то этот должен идти на /api/items/_bulk
3. В запросе идёт json-массив с тем, что мы хотим.
4. В ответе идёт json-ответ с массивом результатов по каждой вставке.
5. Если в будущем захотим параметризировать такой запрос (к примеру, какой-нибудь аналог safe=True из монги, типа в транзакции всё делать или нет) — параметризировать http-заголовком, возможно каким-то своим X-BULK-SAFE=true или типа того. Тут еще надо подумать.
1. Запрос должен идти с заголовком Contrent-Type: application/json (ну, или другим каким-то, в котором возможно слать не тупо ключ-значение, а массив)
2. Если обычный запрос идёт на /api/items/ , то этот должен идти на /api/items/_bulk
3. В запросе идёт json-массив с тем, что мы хотим.
4. В ответе идёт json-ответ с массивом результатов по каждой вставке.
5. Если в будущем захотим параметризировать такой запрос (к примеру, какой-нибудь аналог safe=True из монги, типа в транзакции всё делать или нет) — параметризировать http-заголовком, возможно каким-то своим X-BULK-SAFE=true или типа того. Тут еще надо подумать.
shop.oreilly.com Наверное таки надо разоряться на хорошие книги. Нашел книгу по REST дизайну. Надо бы почитать в электронном варианте, а если хороша будет, то заказать. Изучать всякие джанги с рельсами дело хорошее, но когда не можешь спроектировать приложение, то хоть на scaffold пиши — ничего не получится. А REST таки выглядит весьма перспективным и вкусным делом, да.
Что-то все чаще хочется углубленно разобраться в архитектуре REST. Есть многие непонятные моменты, а уж то, что концепция как таковая многими трактуется по разному — уже и говорить не приходится. Вот возьмем к примеру Ruby On Rails. Базовая концепция в них — RESTful. Ок. Есть операции над ресурсами, и только одна операция над коллекцией. Если заглянуть в Wiki: en.wikipedia.org и посмотреть небольшую табличку в конце, то видно, что над коллекциями так же можно проводить полноценные CRUD операции, а не только Read. Возникает вопрос собственно. А каким образом идеологически правильно можно проводить CRUD операции над коллекциями (например, передача данных, обновление части коллекции или добавление в коллекцию последовательности объектов и так далее), и является ли это RESTful, а не воспаленной фантазией wiki-автора статьи? Не забуду также упомянуть Collections в backbone.js, которые вроде бы с одной стороны вспомогательную функцию несут, с другой стороны вполне могут быть концепцией REST.
Тема в принципе не нова, а часто еще хочется, чтобы RESTful умел и кусочек RPC, и прочие штуки, но вот такой момент все таки волнует. Где оно так сказать, православно описано? Или на базе приведенных концепций нужно исходить из собственных знаний и идеологии? Сколько искал, пока не смог найти адекватного для понимания моим мозгом описания сей прекрасной концепции. Может кто подкинет ссылочек?
Тема в принципе не нова, а часто еще хочется, чтобы RESTful умел и кусочек RPC, и прочие штуки, но вот такой момент все таки волнует. Где оно так сказать, православно описано? Или на базе приведенных концепций нужно исходить из собственных знаний и идеологии? Сколько искал, пока не смог найти адекватного для понимания моим мозгом описания сей прекрасной концепции. Может кто подкинет ссылочек?
Вот смотрю на обе либы, и в обоих по сути используется понятие Resource, которые грубо говоря, как я понял есть не что иное замена controller. Хех. Была Django MTV, стала MVC :D думаю я правильно понял их смысл =)))
Жуйк. Джангожуйк. У меня к тебе вопрос. Насколько приемлимо использование REST в Django приложениях. Точнее даже не приемлимо, а насколько удобно, и достаточно ли просто оно реализуется? Может у кого опыт был. Поделитесь, плиз =)
Завтра выдвигаемся на яхте на ост. Лаврова maps.yandex.ru
Лето, Море, Волны — skimboard marxhome.ru
timelessrepo.com в дополнение
годная статья по второтегу: Nobody understands REST -> blog.steveklabnik.com
наверное самый подробный разбор полетов про authentication в restfull веб сервисах в блоге из 90-х berenddeboer.net
товарищи, расскажите как делают рассово-правильную authentication для REST сервисов. гугл вот говорит что вариантов не так уж много: а) basic / digest auth [1] b) hmac + secret [2]. кто нибудь может поделиться опытом?
[1] tools.ietf.org
[2] ietf.org
[1] tools.ietf.org
[2] ietf.org
Внезапно был запечатлен человеком с фотоаппаратом, который бегал по Рок-Сити и околохудожественно всех фотографировал на концерте зебест-группы "Коридор". Я — на заднем плане : )))
Прочие фото с данного мероприятия тут:
vkontakte.ru
Прочие фото с данного мероприятия тут:
vkontakte.ru
Подумалось тут. На идеологию REST ака CRUD в веб-разработке очень хорошо ложится TDD.
За счет ограниченного числа методов и состояний очень легко должно быть писать тесты под REST-приложения.
За счет ограниченного числа методов и состояний очень легко должно быть писать тесты под REST-приложения.
Out Hall — отличное заведение, для ночный пати. Надоела музыка — можно сходить поиграть в бильярд (очень дешево) или боулинг (тут цены не знаю). Сегодня/вчера ночью особенно замечательно подрыгался под любимые треки BSE, после чего пошел не очень любимый мной rasta jungle.