Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 75
Хорошая статья для того чтобы начать изучение архитектуры, спасибо
>Следовательно, формат данных передаваемых в теле запроса будет всегда XML.
эт не совсем верно. какой формат захочешь — такой и будет, не всегда xml подходит
эт не совсем верно. какой формат захочешь — такой и будет, не всегда xml подходит
«Веб-служба, веб-сервис (англ. web service) — программная система, идентифицируемая строкой URI, чьи общедоступные интерфейсы определены на языке XML» — это из википедии.
«Классическая» служба строится именно на XML. Конечно, можно использовать и json и другие форматы, но это скорее новомодная практика, нежели стандарт.
«Классическая» служба строится именно на XML. Конечно, можно использовать и json и другие форматы, но это скорее новомодная практика, нежели стандарт.
:) Замешкался я с комментарием.
хмл ты фиг получишь с другого домена в отличие от яваскрипта…
Не согласен. Аргументируйте.
проксирование через свой сервер — фиговый вариант.
Вообще то один из вариантов использования кросс доменного запроса это работа через элемент script. Какая разница указано в src. И вообще за кросс доменом будущее ;)
и как ты собираешься получать хмл через элемент скрипт?
JS обертка делается для данных которые получают. Может статью сделаю на эту тему, после предварительных исследований. А тема очень важная.
var myXML = 'here';
;)
;)
выкачай снаяала вот этот хмл: habrahabr.ru/rss/blogs/webdev/38730/fb8d8890e4869cbf60a77b2e9832b26d/
а потом улыбайся
а потом улыбайся
1. закладка долго была открыта, поэтому задержался с ответом который потерял смысл после слов m007
2. парсер скушал XML-теги вокруг here :«)
каков вопрос (»как ты собираешься получать хмл« через элемент скрипт) таков ответ. XML получить не проблема, вопрос лишь в том нужно ли это делать ;)
2. парсер скушал XML-теги вокруг here :«)
«js обёртка» — это и есть «новомодный json». только данные зачем-то передаются виде одной-единственной json-строки, а не в виде дерева объектов.
каков вопрос (»как ты собираешься получать хмл« через элемент скрипт) таков ответ. XML получить не проблема, вопрос лишь в том нужно ли это делать ;)
Эмм… «Ортодоксальный» веб-сервис, если не изменяет память, предполагает использование формата XML.
HTML, строго говоря, подмножество XML
строго говоря, нет) Это XHTML был подмножеством XML, но его разработку забросили
не грех упомянуть rails которые используют rest поумолчанию
Тогда надо упоминать вообще все MVC-фреймворки. Многие из них используют REST. Тот же CakePhp содержит специальный функционал для этого. Уверен, остальные тоже.
Кстати, один из примеров использования REST — Assembla — хостинг для проектов. К слову сказать, удобный: SVN, Trac, Wiki, Scrum и прочие вкусности. Базовый аккаунт пока бесплатен.
мне кажется, это применимо для небольших или несложных решений
Кстати, интерсно. На этом хостинге PUT и POST зачем-то поменяли местами. Т.е. POST используется для создания, а PUT для изменения. Вообще это противорчечит архитектуре, и мне соврешенно непонятно зачем это сделано.
ru.wikipedia.org/wiki/HTTP#POST
это в статье не правильно написано
en.wikipedia.org/wiki/REST#RESTful_example:_the_World_Wide_Web
+ я точно знаю, что в CakePhp для edit используется POST.
Так что я думаю, что вы ошибаетесь.
+ я точно знаю, что в CakePhp для edit используется POST.
Так что я думаю, что вы ошибаетесь.
Это применимо для чего угодно, главное знать как применять.
Если говорить об внутренних вебсервисах проекта, реализующих сервисно-объектную архитектуру, то xml однозначно проигрывает. Имхо, в СОА удобней и эффективней использовать, что-то легковесное и быстрое, например jsonrpc, rest или протоколы обмена данными по типу google buffer protocol или trifft
REST это не архитектура, а метод. Фактически он так в HTML формах и называется — method.
Приписывать четырём методам свойства «архитектуры» из которых реально в браузерах только два поддерживаются — поспешно.
Приписывать четырём методам свойства «архитектуры» из которых реально в браузерах только два поддерживаются — поспешно.
Вы не поняли темы. method в форме, это всего лишь метод передачи запроса. Сама архитектура REST исповедует разделение на ресурсы. Все есть ресурс. Как в ООП — все есть объект. И каждый ресурс имеет свой адрес (url). Т.е. когда вы запрашиваете книгу (как в статье) по урлу и передаете GETом параметры через вопросик, это уже не REST. REST предполагает, что книга это ресурс и у нее есть свой адрес. Методов GET, POST, PUT и DELETE достаточно для работы с такой моделью.
Я понимаю что это предполагает «всё объект» и я сам использовал REST в java.
Может мы по разному понимаем определение «архитектуры», помоему это нечто фундаментальное на чём основывается проект. Это может быть язык, framework как его расширение, наконец совокупность используемых методов.
REST же практически используется как правило только как интерфейс — для общения с внешними сервисами, подобно SOAP и XML-RPC, просто будучи значительно проще имеет большую распространённость (благодаря GET и POST). Называть этод метод платформой и уж тем более архитектурой — глупо, если конечно вы не пишете приложение где этод метод лежит в основе всего, но это опять же проблематично потому что браузеры не поддерживают PUT и DELETE.
Может мы по разному понимаем определение «архитектуры», помоему это нечто фундаментальное на чём основывается проект. Это может быть язык, framework как его расширение, наконец совокупность используемых методов.
REST же практически используется как правило только как интерфейс — для общения с внешними сервисами, подобно SOAP и XML-RPC, просто будучи значительно проще имеет большую распространённость (благодаря GET и POST). Называть этод метод платформой и уж тем более архитектурой — глупо, если конечно вы не пишете приложение где этод метод лежит в основе всего, но это опять же проблематично потому что браузеры не поддерживают PUT и DELETE.
Соглашусь, что REST в каком-то смысле сложно обозвать архитектурой.
Это скорее подход. Как ООП ;)
Но, с другой стороны, чтобы в полной мере реализовать REST, понадобится разработать под это дело архитектуру. Которую потом придется обозвать REST-архитектурой.
Так что считаю спорить о том, является ли REST архитектурой или не является, пустым делом ;)
Это скорее подход. Как ООП ;)
Но, с другой стороны, чтобы в полной мере реализовать REST, понадобится разработать под это дело архитектуру. Которую потом придется обозвать REST-архитектурой.
Так что считаю спорить о том, является ли REST архитектурой или не является, пустым делом ;)
Вы путаете вариант реализации с основой. HTTP GET-PUT-POST-DELETE это реализация CRUD для HTTP-протокола. Она наиболее часто используется, поэтому и возникает путаница.
REST — это архитектeра. Она строится на принципах, которые вы сами же и назвали. Но url — это именно universal resource locator, универсальный идентификатор ресурса, а не ссылка в интернете. Вобщем, если совсем просто согласно REST — в заголовке — что сделать и с каким ресурсом, а данные в теле запроса. А какой протокол используется — дело десятое.
REST — это архитектeра. Она строится на принципах, которые вы сами же и назвали. Но url — это именно universal resource locator, универсальный идентификатор ресурса, а не ссылка в интернете. Вобщем, если совсем просто согласно REST — в заголовке — что сделать и с каким ресурсом, а данные в теле запроса. А какой протокол используется — дело десятое.
Что я ничего не понял, что вы тут нагородили )
«HTTP GET-PUT-POST-DELETE это реализация CRUD для HTTP-протокола.» согласен.
«Она наиболее часто используется, поэтому и возникает путаница.» Какая путаница? С чем?
«Но url — это именно universal resource locator, универсальный идентификатор ресурса, а не ссылка в интернете.» Это где я URL ссылкой обозвал *осматривается* :)
«HTTP GET-PUT-POST-DELETE это реализация CRUD для HTTP-протокола.» согласен.
«Она наиболее часто используется, поэтому и возникает путаница.» Какая путаница? С чем?
«Но url — это именно universal resource locator, универсальный идентификатор ресурса, а не ссылка в интернете.» Это где я URL ссылкой обозвал *осматривается* :)
Сори, html-редактор глюканул.
hinchcliffe.org/img/restinteractionvisual.png
hinchcliffe.org/img/restinteractionvisual.png
Человек, который это писал молодец. Но, зачем было сюда приплетать AMF.
AMF — это формат передачи данных. Вся его соль в том, что он бинарный (меньше объем передаваемых данных) и позволяет передавать типизированные данные. Используя разные прослойки (например AMFPHP) вы можете работать на стороне сервера с объектами, передавать их по протоколу и во Flash получить типизированный объект. В итоге, не надо ничего парсить, ничего выдумывать. Просто тупо вызываем необходимый нам метод.
Кстати, AMF работает быстрее, чем ручное распаршивание данных.
Как эффективно (при минимальных затратах) прикрутить REST во Flash я не знаю. Буду рад, если кто-нибудь прояснит.
AMF — это формат передачи данных. Вся его соль в том, что он бинарный (меньше объем передаваемых данных) и позволяет передавать типизированные данные. Используя разные прослойки (например AMFPHP) вы можете работать на стороне сервера с объектами, передавать их по протоколу и во Flash получить типизированный объект. В итоге, не надо ничего парсить, ничего выдумывать. Просто тупо вызываем необходимый нам метод.
Кстати, AMF работает быстрее, чем ручное распаршивание данных.
Как эффективно (при минимальных затратах) прикрутить REST во Flash я не знаю. Буду рад, если кто-нибудь прояснит.
REST is not about url design only, REST is not opposite to RPC (even XML-RPC), REST is about using HTTP in natural way, without any unreasonable overhead
Почему-то REST всем нравится. Почему-то каждый, кто открывает его для себя наполняется энтузиазмом и с криком «Так правильно, да будет так!!!» бьет себя пяткой в грудь и обещает начать это дело использовать. Вот только на этом дело обычно и останавливается.
REST призывает использовать HTTP по прямому назначению, ровно так, как он изначально задумывался, без всяких его расширений и перегрузок. Но в наших реалиях это мало возможно. Все стремятся использовать ЧПУ (красивые урлы, если кто не в курсе). Это хорошо, это дает возможность сказать, что каждый наш ресурс имеет урл, но это еще далеко от REST.
Поясню. REST предполагает, что все есть ресурс. Таким образом, каждый комментарий к этой статье должен иметь свой URL и быть по нему доступен. И каждый коммент должен подгружаться отдельным запросом.
Все как в ООП. Если у вашего объекта «магазин» есть метод «инвентарь», то инвентарь это тоже объект, и каждый предмет в инвентаре тоже есть объект, и загружается соответственно отдельно.
Но с другой стороны REST на этом не настаивает. Вот жешь блин )))
Короче. REST — это мечта, которая на практике не эффективна. Так же как красивый код и безупречная архитектура. Рано или поздно, станет тесно и не удобно.
Кстати, такая вещь как cookie должна противоречить REST.
Все сказанное сугубо IMHO. Конструктивные критика и комментарии приветствуются )))
REST призывает использовать HTTP по прямому назначению, ровно так, как он изначально задумывался, без всяких его расширений и перегрузок. Но в наших реалиях это мало возможно. Все стремятся использовать ЧПУ (красивые урлы, если кто не в курсе). Это хорошо, это дает возможность сказать, что каждый наш ресурс имеет урл, но это еще далеко от REST.
Поясню. REST предполагает, что все есть ресурс. Таким образом, каждый комментарий к этой статье должен иметь свой URL и быть по нему доступен. И каждый коммент должен подгружаться отдельным запросом.
Все как в ООП. Если у вашего объекта «магазин» есть метод «инвентарь», то инвентарь это тоже объект, и каждый предмет в инвентаре тоже есть объект, и загружается соответственно отдельно.
Но с другой стороны REST на этом не настаивает. Вот жешь блин )))
Короче. REST — это мечта, которая на практике не эффективна. Так же как красивый код и безупречная архитектура. Рано или поздно, станет тесно и не удобно.
Кстати, такая вещь как cookie должна противоречить REST.
Все сказанное сугубо IMHO. Конструктивные критика и комментарии приветствуются )))
>Кстати, такая вещь как cookie должна противоречить REST.
объясните?
объясните?
Подпишусь под каждым словом. От себя добавлю, может потому что использование REST непривычно. Сложно просто смотреть на вещи, если привык смотреть сложно. :-)
Абсолютно верно. Поставил бы плюс, да нечем.
Добавлю еще, что ЧПУ все-таки играют некоторую роль в SEO (большую или малую — другой вопрос).
Да и юзеру приятней видеть УРЛ вида www.theverybestshop.aa/catalog/notebooks/, чем безликое .../catalog/124 в тех же результатах поиска.
Добавлю еще, что ЧПУ все-таки играют некоторую роль в SEO (большую или малую — другой вопрос).
Да и юзеру приятней видеть УРЛ вида www.theverybestshop.aa/catalog/notebooks/, чем безликое .../catalog/124 в тех же результатах поиска.
список комментариев тоже объект.
ничто не мешает выполнить денормализацию на уровне представления, даже наоборот :)
ничто не мешает выполнить денормализацию на уровне представления, даже наоборот :)
Если список комментариев представлять как объект, то этот объект должен тогда включать в себя вообще все комментарии, иначе это уже фигня какая-то получится. Список комментариев это должен быть метод объекта «сообщение», который возвращает список объектов «комментарий».
Но это все не важно в данном случае. Мы ведь обсуждаем идеальный вариант архитектуры с теоретической точки зрения. Т.е. денормализация в данном случае нам побоку. На практике это конечно будет по другому, но обсуждаем мы идеальный вариант. Как-то так ;)
Но это все не важно в данном случае. Мы ведь обсуждаем идеальный вариант архитектуры с теоретической точки зрения. Т.е. денормализация в данном случае нам побоку. На практике это конечно будет по другому, но обсуждаем мы идеальный вариант. Как-то так ;)
Покажите мне место где описан «стандарт» под названием REST?
C RPC все понятно www.xmlrpc.com/spec
Еще, нафига вся эта канитель с запросами PUT и DELETE, любой нормальный сисадмин запретит вебсерверу принимать такие запросы.
Скажете что имя метода передается в переменной method? Тогда зачем вся эта ширма и намеки на стандарт? Давайте так и будем говорить «на rest сервер всегда делается POST запрос в котором передается переменная method в котором мы указываем что именно хотим.
C RPC все понятно www.xmlrpc.com/spec
Еще, нафига вся эта канитель с запросами PUT и DELETE, любой нормальный сисадмин запретит вебсерверу принимать такие запросы.
Скажете что имя метода передается в переменной method? Тогда зачем вся эта ширма и намеки на стандарт? Давайте так и будем говорить «на rest сервер всегда делается POST запрос в котором передается переменная method в котором мы указываем что именно хотим.
Причем тут стандарт, когда это архитектурный стиль?
Потому что реализация этого стиля лежит полностью на разработчике сервиса. Сторонним разработчикам нельзя будет просто назвать имена свои методов (или точнее Урлы) и сказать мол «нате пользуйтесь». И если нужно будет этот сервис сделать публичным то прийдется написать самом соответствующие библиотеки на разных языках программирования.
А его реализация и не лежит на разработчике. Стиль не надо реализовывать — его можно использовать или нет в своих сервисах. А о том, что REST имеет недостатки — это само собой. В отличие от «Classic Web Services», здесь нет WSDL и пользователи сервиса не могут получать метаданные от самого сервиса (в том числе обновления в наборах методов конечных точек), а вынуждены, как вариант, запрашивать их с некоего стороннего сервиса.
Однако, как раз таки «Урлы» назвать можно будет, как раз сказав «нате пользуйтесь». Однако параллельно с этим нужно будет сообщить правила работы с сервисом.
Архитектура REST прекрасно показывает себя в одних приложениях, SOAP и WSDL — в других. Причем, последнее — более старое и зрелое, и более, так сказать, Enterprise-ready для сложных систем.
А еще насчет REST надо сказать, что крайне редко удается следовать концепции «pure REST», то есть с точно ограниченным количеством методов конечной точки и в точном соответствии с общими правилами работы с сервисами (включая форматы).
Однако, как раз таки «Урлы» назвать можно будет, как раз сказав «нате пользуйтесь». Однако параллельно с этим нужно будет сообщить правила работы с сервисом.
Архитектура REST прекрасно показывает себя в одних приложениях, SOAP и WSDL — в других. Причем, последнее — более старое и зрелое, и более, так сказать, Enterprise-ready для сложных систем.
А еще насчет REST надо сказать, что крайне редко удается следовать концепции «pure REST», то есть с точно ограниченным количеством методов конечной точки и в точном соответствии с общими правилами работы с сервисами (включая форматы).
это не стандарт, это скорее сборник рекомендаций
Класс, удивительно, что прежде эта тема не затрагивалась на Хабре
Статья хорошая. Одно «но» — w3c рекомендует вместо URL использовать более общее понятие URI.
Как оказалось, большая проблема найти хостера, который разрешает доступ к HTTP_RAW_POST_DATA.
Посему «PUT /info/ (Create) — Данные передаются в теле запроса без применения кодирования» становится неразрешенным действием. Так что REST доступент только профи, которые могут себе позволить содержать выделенный сервер, чтобы настроить его как надо.
Посему «PUT /info/ (Create) — Данные передаются в теле запроса без применения кодирования» становится неразрешенным действием. Так что REST доступент только профи, которые могут себе позволить содержать выделенный сервер, чтобы настроить его как надо.
прошу не ругать, но объясните на пальцах пожалуйста, как при такой архитектуре мы будем идентифицировать пользователя
По-моему, автор жестоко перепутал POST и PUT. POST должен создавать новые ресурсы, а PUT — обновлять их.
хочу узнать побольше про REST,
подскажите пожалуйста
а как может выглядеть url get запроса скажем, для получения комментариев данного топика
если надо получить скажем за раз 20 или 50 штук (типа limit 50 offset 100)
habrahabr.ru/blogs/webdev/38730/comments/?
подскажите пожалуйста
а как может выглядеть url get запроса скажем, для получения комментариев данного топика
если надо получить скажем за раз 20 или 50 штук (типа limit 50 offset 100)
habrahabr.ru/blogs/webdev/38730/comments/?
У меня есть вопрос, а что если нам надо сделать удаление нескольких элементов, с ид например 15, 27 и 102, то как должна выглядеть ссылка или как должна сабмититса форма? не пойму.
DELETE /items/15;27;102
По-моему в статье сделано одно ключевое упущение. Что делает ее в общем-то неправильной и что вынудило автора написать «важное дополнение», которое в общем-то не изменило ситуации.
Важно понимать что PUT — идемпотентный (idempotent) метод (также как и GET). Иными словами один и тот же запрос должен иметь один и тот же результат в независимости от количества повторений.
Методы же POST и DELETE такими не являются. POST должен каждый раз добавлять данные в коллекцию, либо к объекту. DELETE — уничтожает объект или данные, два раза уничтожить одно и то же нельзя.
Итак, когда же использовать POST, а когда PUT?
При добавлении, вы добавляете данные и с заданным ID?
Да: «PUT /items/3» — в этом случае мы жестко задали, что хотим создать элемент c ID = /items/3
Нет: «POST /items/» — добавит новый item в коллекцию items, ID будет назначен автоматически следующим по счету
Если вы обновляете существующие данные, то однозначно:
«PUT /items/3» — обновит элемент с ID = /items/3
Важно понимать что PUT — идемпотентный (idempotent) метод (также как и GET). Иными словами один и тот же запрос должен иметь один и тот же результат в независимости от количества повторений.
Методы же POST и DELETE такими не являются. POST должен каждый раз добавлять данные в коллекцию, либо к объекту. DELETE — уничтожает объект или данные, два раза уничтожить одно и то же нельзя.
Итак, когда же использовать POST, а когда PUT?
При добавлении, вы добавляете данные и с заданным ID?
Да: «PUT /items/3» — в этом случае мы жестко задали, что хотим создать элемент c ID = /items/3
Нет: «POST /items/» — добавит новый item в коллекцию items, ID будет назначен автоматически следующим по счету
Если вы обновляете существующие данные, то однозначно:
«PUT /items/3» — обновит элемент с ID = /items/3
Говорят, грядет http 1.2. И, говорят, REST будет в него вшит. Кто-нибудь может рассказать подробности? Источник.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура REST