Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 57
А я в FF использую Firebug
Выглядит отлично.
Только насколько я понял мы ограничены GET?
Только насколько я понял мы ограничены GET?
очевидно да,
но ничего не стоит добавить выпадающий список с вариантами GET, POST
чтобы была возможность выбирать…
а так — сам тестировал c помощью firebug
но ничего не стоит добавить выпадающий список с вариантами GET, POST
чтобы была возможность выбирать…
а так — сам тестировал c помощью firebug
Добавить-то можно, но работать не будет.
Ибо кросс-доменный запрос, он только GET и только jsonp.
Ибо кросс-доменный запрос, он только GET и только jsonp.
XSS фильтр, насколько я помню, отключается в настройках лисы(about:config).
При честной имитации клиента смысла в этом не много, но за инфу — спасибо, есть идейка.
У всех клиентов вы его не отключите.
У себя мы сделали проброс через Nginx.
У себя мы сделали проброс через Nginx.
### EMS API
location /api/rest {
proxy_pass emspost.ru;
proxy_redirect off;
proxy_set_header Host "emspost.ru";
proxy_set_header Cookie "";
client_max_body_size 1m;
client_body_buffer_size 128k;
proxy_connect_timeout 10;
proxy_send_timeout 10;
proxy_read_timeout 10;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_cache_valid 30m;
}
## EMS API
А чем firebug не угодил?
curl -d @request_file.xml "url string here"и, в завершение ликбеза по man'у
В любом случае, предположение об отсутствии «приличного инструмента для отладки json» сомнительно.
-H "content-type: application/soap+xml"
-b "some cookies"В любом случае, предположение об отсутствии «приличного инструмента для отладки json» сомнительно.
Хотел съязвить, но не буду.
curl не столь удобен и слишком дальнобойный, у него же нет проблем с кросс-доменным запросом.
А мне нужен был нативный браузерный аналог. Желательно — наглядный.
curl не столь удобен и слишком дальнобойный, у него же нет проблем с кросс-доменным запросом.
А мне нужен был нативный браузерный аналог. Желательно — наглядный.
Обратите внимание на количество сделанных вами оговорок: «требуется именно имитировать ajax-клиента», «кросс-доменный запрос», «все лагает, памяти на всех не напасешься», кроссплатформенность и т.д.
Стоило написать всё это в статье. Без этих оговорок велосипед не нужен, а все вопросы решаются общеиспользуемыми инструментами.
Стоило написать всё это в статье. Без этих оговорок велосипед не нужен, а все вопросы решаются общеиспользуемыми инструментами.
ТЮ! И галушки Вам малы?! :)
Парирую — стоило в ответе написать «велосипед МНЕ [имярек] не нужен» и «вопросы решаются МНОЮ [имярек] общеиспользуемыми».
Ну, рад за Вас. Мне эти инструменты показались неудобны, отсюда и заметка.
Стоило написать всё это в статье. Без этих оговорок велосипед не нужен, а все вопросы решаются общеиспользуемыми инструментами.
Парирую — стоило в ответе написать «велосипед МНЕ [имярек] не нужен» и «вопросы решаются МНОЮ [имярек] общеиспользуемыми».
Ну, рад за Вас. Мне эти инструменты показались неудобны, отсюда и заметка.
Можно, только тогда уж -X [GET|POST|PUT|DELETE|whatever]
Как бы регистр как бы важен
Как бы регистр как бы важен
Ну, как тут многие писали, для такого можно и Firebug использовать,
а если нужен полноценный REST client в браузере, то вот пожалуйста addons.mozilla.org/en-US/firefox/addon/restclient/
а если нужен полноценный REST client в браузере, то вот пожалуйста addons.mozilla.org/en-US/firefox/addon/restclient/
Хм, ну я использую JSONView под Firefox
«бобро» это название либы :))?
Fiddler вам в помощь. Велосипед удобный, но все таки велосипед :)
+1 способ посмотреть быстро, в контексте браузера с любой страницы (если на ней нет любимого фреймворка, не забыть подгрузить)
habrastorage.org/storage/ac369cf6/7b8d7f64/54c22b30/54ecd8f6.png
habrastorage.org/storage/ac369cf6/7b8d7f64/54c22b30/54ecd8f6.png
А зачем вам писать «city--Moskva»? Почему не
['city', 'moskva'] или {'city': 'moskva'}? Я не могу понять какой вариант удачнее, потому что мне неизвестно что скрывается за вашими данными.
то что у вас тут написано — это не REST это JSON-RPC
по концепции REST ресурс должен обладать уникальным адресом, а в данном случае метод передается JSON формате, а урл для всех методов один и тот-же.
Более того, если Вы хотите получить данные, то обязательно должен быть запрос GET, именно для этого он и создан. А в данном случае для получаения данных испольуется POST (судя по загловку поля «тело запроса»). Ну и так далее.
Никакого отношения к REST данная штука не имеет.
по концепции REST ресурс должен обладать уникальным адресом, а в данном случае метод передается JSON формате, а урл для всех методов один и тот-же.
Более того, если Вы хотите получить данные, то обязательно должен быть запрос GET, именно для этого он и создан. А в данном случае для получаения данных испольуется POST (судя по загловку поля «тело запроса»). Ну и так далее.
Никакого отношения к REST данная штука не имеет.
то что у меня тут написано — это строка поиска, разбитая на две части.
И тестировать этим, что тут написано, можно что угодно, что может отдать jsonp ответ. Совершенно без разницы, как будет выглядеть запрос.
Ну и так далее.
Аааа… а вот скажите мне, как Вам представляется возможным отдать из браузера постом на любой сервис данные и получить что-то вменяемое и отображаемое в ответ?
Вот после этого будем обсуждать Ваши «так далее», а то получается «не читал, но осуждаю».
Право слово, Ваша категоричность впереди :)
И тестировать этим, что тут написано, можно что угодно, что может отдать jsonp ответ. Совершенно без разницы, как будет выглядеть запрос.
Ну и так далее.
Аааа… а вот скажите мне, как Вам представляется возможным отдать из браузера постом на любой сервис данные и получить что-то вменяемое и отображаемое в ответ?
Вот после этого будем обсуждать Ваши «так далее», а то получается «не читал, но осуждаю».
Право слово, Ваша категоричность впереди :)
Ну вы же говорите про REST, а не про что-то вами придуманное и на коленке поднятое.
А REST включает в себя четыре метода — GET, POST, DELETE, PUT, и каждый используется под определенные нужды.
То что браузеры не умеют двух из выше изложенных, а один не умеют передавать на другие домены — это не проблема разработчиков REST сервисов.
Тоесть, это проблема, если нужно именно для браузеров на чужих доменах писать.
А REST включает в себя четыре метода — GET, POST, DELETE, PUT, и каждый используется под определенные нужды.
То что браузеры не умеют двух из выше изложенных, а один не умеют передавать на другие домены — это не проблема разработчиков REST сервисов.
Тоесть, это проблема, если нужно именно для браузеров на чужих доменах писать.
В заголовке написано: «тестирвоанеи REST-сервиса», а в скриншоте пример не-REST. И вообще в статье больше про REST не встречается. Да здорово, что инструмент может тестировать что угодно, я рад. Но название статьи не соответсвует содержанию. Назовите тогда «Тестировани веб сервисов».
Вы хотите чтоб я рассказал про RESTFul интерфейсы?
amzn.to/gVjZxM вот хорошая книга с теорие
а Graph API от Facebook — отличный пример.
Моя категоричность связана с тем, что сейчас модно все веб-сервисы называть RESTful. Хотя те, кто называет, помоему, ничего не понимают даже о базовых понятиях концепции. Сужу я по реализации.
Например mail.ru API упорно в документации называется REST, но я ничего из концепции REST не увидел вообще. Даже наоборот.
Вы хотите чтоб я рассказал про RESTFul интерфейсы?
amzn.to/gVjZxM вот хорошая книга с теорие
а Graph API от Facebook — отличный пример.
Моя категоричность связана с тем, что сейчас модно все веб-сервисы называть RESTful. Хотя те, кто называет, помоему, ничего не понимают даже о базовых понятиях концепции. Сужу я по реализации.
Например mail.ru API упорно в документации называется REST, но я ничего из концепции REST не увидел вообще. Даже наоборот.
извиняюсь, пост относитя к ветке обсуждений выше.
Но название статьи не соответсвует содержанию. Назовите тогда «Тестировани веб сервисов».
Не могу, так мы смутим остальных, которые будут интересоваться, как же этим можно протестировать комментарии в их любимой жежешечке или вконтактик.
И, потом, инструмент позволяет проверить работоспособность GET-части RESTFul-сервиса, это Вы отрицать не будете?
А инкриминировать мне создание сервиса, который не REST? Ведь я никакого сервиса не делал :)
Так что я перед законом чист.
это уже отмазки :-)
но, тестировать GET часть RESTful интерфейса можно, но согласитесь, что не для этого инструмент предназначен, а как раз наоборот. Иначе зачем тело поста?
может перед законом Вы и чисты, но лично в моих глазах — Вы наглый врун и вводите людей в заблуждение, которое и без Вас уже основательно укоренилось.
но, тестировать GET часть RESTful интерфейса можно, но согласитесь, что не для этого инструмент предназначен, а как раз наоборот. Иначе зачем тело поста?
может перед законом Вы и чисты, но лично в моих глазах — Вы наглый врун и вводите людей в заблуждение, которое и без Вас уже основательно укоренилось.
но, тестировать GET часть RESTful интерфейса можно, но согласитесь, что не для этого инструмент предназначен, а как раз наоборот. Иначе зачем тело поста?
Если я — наглый врун (хвалите меня, хвалите!), то вы последний буквоед, лечащий по фотографии.
request body означает по факту «часть после ?» так как сделать запрос можно только GET, у которого body нет (в части реализации оного браузером).
Если религия не позволяет — ну не используйте вы это поле, представьте, что пишите RESTful и пишите свой путь до данных только в верхней части.
Дальше, jsonp вааще тогда противопоказан RESTful-евангелистам, бо добавляет богомерзкий ?callback=[whatever] в незапятнанный всякой дрянью URI. Так что или флеш, или фреймы — ваше все, или CORS (может быть).
Как это называется — астронавты? Ага?
курсы повышения квалификации стоят денег :-) но проведу небольшой ликбез по вышеприведенным вопросам:
Идеологически!!! не GET запросе не должно быть тела.
tools.ietf.org/html/rfc2616#section-9.3 — там написано
Тоесть четко сказано, что ресурс должен быть четко идентифицирован URI а не содержимым тела.
Согласно тому-же RFC можно тело запроса не обязательно, оно опциоанльно, более того в ранних версиях вообще нельзя было добавлять.
Во всех учебниках REST найдете строку: Must not inclue message body to GET request.
Именно потому, что тело не нужно для отладки, ваш инструмент автоматически становится бесполезным, так как ничем не отличается от адресной строки.
JSON не противоречит REST — посмотрите на реализацию Graph API от Facebook.
Идеологически!!! не GET запросе не должно быть тела.
tools.ietf.org/html/rfc2616#section-9.3 — там написано
The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI.Тоесть четко сказано, что ресурс должен быть четко идентифицирован URI а не содержимым тела.
Согласно тому-же RFC можно тело запроса не обязательно, оно опциоанльно, более того в ранних версиях вообще нельзя было добавлять.
Во всех учебниках REST найдете строку: Must not inclue message body to GET request.
Именно потому, что тело не нужно для отладки, ваш инструмент автоматически становится бесполезным, так как ничем не отличается от адресной строки.
JSON не противоречит REST — посмотрите на реализацию Graph API от Facebook.
?callback=[whatever] — а это вообще каким боком к JSON или JSON-RPC? Я так понимаю речь идет о JS? так как потом упоминается флеш и фреймы. Я вас удивлю, есть еще несколько тысячь языков программирования. Я например пользуюсь C/C++/Objective-C.ну, к тому что я наглый врун и форменный невежда я еще и жуткий скряга, так что денег не будет, можете закачать свой комментарий обратно. :)
Не пользуйтесь. Нет, не так — конкретно Вам я запрещаю пользоваться этим инструментом. Кашрут надо блюсти.
«несколько тысячь языков программирования.» — ну да. Есть еще русский. Хотите об этом поговорить?
Ура! да, Вы правильно меня поняли, речь идет о js(only). Ну или покажите мне финт ушами с нативным C/C++/Objective-C, который исполнит мой FF.
Не пользуйтесь. Нет, не так — конкретно Вам я запрещаю пользоваться этим инструментом. Кашрут надо блюсти.
«несколько тысячь языков программирования.» — ну да. Есть еще русский. Хотите об этом поговорить?
Ура! да, Вы правильно меня поняли, речь идет о js(only). Ну или покажите мне финт ушами с нативным C/C++/Objective-C, который исполнит мой FF.
Русский не мой родной язык, так что стараюсь писать без ошибок. Извиняюсь за допущенную. Но считаю, что к сути вопроса это не относится.
Как раз суть в том, что на любом языке можно взаимодействовать с веб-сервисом, хоть по JSON-RPC хоть по REST API. И сам веб-сервис можно построить тоже на любом языке.
При чем здесь исполнение C/C++ кода в FF? Друг мой, вы пытаетесь увести меня в болото от сути вопроса. Считаю беседу законченной, ибо оплату за предыдущий ликбез не получил :-)
Как раз суть в том, что на любом языке можно взаимодействовать с веб-сервисом, хоть по JSON-RPC хоть по REST API. И сам веб-сервис можно построить тоже на любом языке.
При чем здесь исполнение C/C++ кода в FF? Друг мой, вы пытаетесь увести меня в болото от сути вопроса. Считаю беседу законченной, ибо оплату за предыдущий ликбез не получил :-)
Вообще говоря, многие (два из из двух, на которых писал REST интерфейсы :) ) фреймворки (серверные), поддерживающие REST, допускают возможность переопределения метода через параметр запроса, прежде всего потому что, HTML (а значит и браузеры) не предусматривает других методов кроме GET и POST, в частности PUT и DELETE, например, example.com/user/1?_method=DELETE удалит юзера. Надо проверить, сработает ли это с POST и будут ли транслироваться параметры из тела GET запроса в POST/PUT/DELETE. До этого не пробовал отправлять запросы с телом через GET.
example.com/user/1?_method=DELETE — это автоматически перестает быть REST.То что это позволяют делать фрейворки — так это аспекты реализации конкретного ПО, но никак не расширяет REST концептию.
Ясно, что браузером полноценный REST клиент не сделаешь. Да и не для этого браузеры и сделаны. Хотя можно допилить любой опен-сорс браузер, но зачем?
Какой из принципов или концепций REST это нарушает? Вообще REST это даже не протокол, это стиль архитектуры приложения, как и парсить запросы решает приложение, не говоря о том, что REST вовсе не обязан быть поверх HTTP в принципе.
REST — это архитектура прилоежний, никто не утверждал, что это пртокол. Но это не значит, что нет четких правил и концепций, иначе нельзя бы было понять что есть REST а что нет.
ну речь в статье идет о WEB — сервисе, значит поверх HTTP.
Вот из википедии:
Параметры в запросе не противоречат в запросе, но они не должны относится к идентификации ресурса. Например параметрами можно передавать секретный токен, или дату обращения, или идентификатор сессии. Но не то что касается доступа к ресурсу (ведь именно в этом вся суть архитектуры).
В данном случае вы передаете через Гет вообще метод удаления. Получается противоречие, Get подразумевает получаение данных и является безопасным. А метод Delete не является безопасным. И как тут на уровне протокола понять что именно этот Get безопасен?
В общем я снизу накидал ссылок, если интересно — почитаете и постараетесь вникнуть, если нет — мне тем более незачем убеждать в чем-нибудь кого-нибудь.
ну речь в статье идет о WEB — сервисе, значит поверх HTTP.
Вот из википедии:
A RESTful web service (also called a RESTful web API) is a simple web service implemented using HTTP and the principles of REST. Параметры в запросе не противоречат в запросе, но они не должны относится к идентификации ресурса. Например параметрами можно передавать секретный токен, или дату обращения, или идентификатор сессии. Но не то что касается доступа к ресурсу (ведь именно в этом вся суть архитектуры).
В данном случае вы передаете через Гет вообще метод удаления. Получается противоречие, Get подразумевает получаение данных и является безопасным. А метод Delete не является безопасным. И как тут на уровне протокола понять что именно этот Get безопасен?
В общем я снизу накидал ссылок, если интересно — почитаете и постараетесь вникнуть, если нет — мне тем более незачем убеждать в чем-нибудь кого-нибудь.
Параметры в запросе не противоречат в запросе,Параметры в запросе не противоречат концепции
GET не является безопасным, это соглашение, но не требование. Иначе очень большое количество ресурсов нельзя было бы назвать доступными по HTTP, но они нарушают идеологию, а не формальные требования HTTP и потому по HTTP доступны.
«Мой» веб-сервис никак не противоречит «вашему» определению. Он реализован с использованием HTTP и принципов REST. Он полностью совместим с любым «референсным» RESTful клиентом, но предоставляет возможность полноценно работать и клиентам, которые не умеют отправлять POST, PUT и DELETE, не нарушая идеологию REST — протокол обмена данными уровня приложения использует HTTP в качестве транспортного протокола немного не так, как «референсная» реализация RESTful web service, но от этого «моя» реализация не перестаёт быть RESTful.
«Мой» веб-сервис никак не противоречит «вашему» определению. Он реализован с использованием HTTP и принципов REST. Он полностью совместим с любым «референсным» RESTful клиентом, но предоставляет возможность полноценно работать и клиентам, которые не умеют отправлять POST, PUT и DELETE, не нарушая идеологию REST — протокол обмена данными уровня приложения использует HTTP в качестве транспортного протокола немного не так, как «референсная» реализация RESTful web service, но от этого «моя» реализация не перестаёт быть RESTful.
GET безопасный для REST, так как REST web services испольузет HTTP методы в качестве команд управления ресурсов. Да именно так и родился принцип REST.
Я не говорил, что GET безопасный для HTTP, там даже таких соглашений нет, как безопысный вызов.
Если утверждаете, что «ваш» веб сервис не перестает быть RESTful, тогда объясните в каком именно месте он соответсвует архитектуре REST?
Я встречал в переписке данных подход (когда метод работы с ресурсом передается в качестве параметра запроса, а не в качестве метода протокола), некоторые его называют «тунелирование» и даже видел «холивар» на эту тему. Мы тоже можем спорить долго на эту тему. Но в описании REST четко сказано, что для управления ресурсами: получение, удаление, обновление… используются соответствующие методы HTTP. В данном случае, я лично считаю, что если это требование не соблюдать, то получается что архитектура не соответствует REST.
Я не говорил, что GET безопасный для HTTP, там даже таких соглашений нет, как безопысный вызов.
Если утверждаете, что «ваш» веб сервис не перестает быть RESTful, тогда объясните в каком именно месте он соответсвует архитектуре REST?
Я встречал в переписке данных подход (когда метод работы с ресурсом передается в качестве параметра запроса, а не в качестве метода протокола), некоторые его называют «тунелирование» и даже видел «холивар» на эту тему. Мы тоже можем спорить долго на эту тему. Но в описании REST четко сказано, что для управления ресурсами: получение, удаление, обновление… используются соответствующие методы HTTP. В данном случае, я лично считаю, что если это требование не соблюдать, то получается что архитектура не соответствует REST.
RFC 2616
Во всех местах :) Любой REST вызов он обработает согласно всем принципам и концепциям. Единственное его отличие от «референсного » REST веб сервиса один условный оператор в «middleware» (между веб-сервером и контроллерами приложения) или вообще в конфигах веб-сервера (Си-образный псевдокод):
Вы считаете, что такой оператор «туннелирования» (довольно удачный термин) или вообще аналогичная директива конфига веб-сервера настолько ломает архитектуру приложения, что её уже не назвать REST? Ваше право, но я свои сервисы с такой директивой буду называть RESTful, хотя бы потому что если не знать о «туннелировании», то от «настоящего» RESTFul со стороны его не отличить, разве что случайно использовать параметр _method в запросе, но необходимости такой не будет.
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered «safe».
Во всех местах :) Любой REST вызов он обработает согласно всем принципам и концепциям. Единственное его отличие от «референсного » REST веб сервиса один условный оператор в «middleware» (между веб-сервером и контроллерами приложения) или вообще в конфигах веб-сервера (Си-образный псевдокод):
if (isset(request.params['_method']))
{
request.method = request.params['_method'];
unset(request.params['_method']);
}Вы считаете, что такой оператор «туннелирования» (довольно удачный термин) или вообще аналогичная директива конфига веб-сервера настолько ломает архитектуру приложения, что её уже не назвать REST? Ваше право, но я свои сервисы с такой директивой буду называть RESTful, хотя бы потому что если не знать о «туннелировании», то от «настоящего» RESTFul со стороны его не отличить, разве что случайно использовать параметр _method в запросе, но необходимости такой не будет.
еще хочу добавить для тех, кто считает что я сильно придирчив. На хабре уже описывались принципы REST достаточно кратко и понятно, рекомендую очень ознакмится с ними тем, кто не еще не знаком:
habrahabr.ru/blogs/webdev/50147/
habrahabr.ru/blogs/webdev/108993/
habrahabr.ru/blogs/webdev/38730/
ну и в конец-концов: habrahabr.ru/search/?q=REST
Очень хотелось-бы, чтоб мой пост прочитал Александр Терехов (api.mail.ru) и убрал из документации везде мелькающие слова «REST API» или инициировал переделку АПИ под рест.
habrahabr.ru/blogs/webdev/50147/
habrahabr.ru/blogs/webdev/108993/
habrahabr.ru/blogs/webdev/38730/
ну и в конец-концов: habrahabr.ru/search/?q=REST
Очень хотелось-бы, чтоб мой пост прочитал Александр Терехов (api.mail.ru) и убрал из документации везде мелькающие слова «REST API» или инициировал переделку АПИ под рест.
SoapUI мой выбор.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отладка REST-сервиса на коленке — готовое решение