Комментарии 28
НЛО прилетело и опубликовало эту надпись здесь
Как наиболее универсальная архитектура построения веб-приложения, типа минимальный базис, из которого все выводится.
НЛО прилетело и опубликовало эту надпись здесь
Ну, тут элемент словоблудия есть конечно, согласен, имелось в виду, что диспетчеризацию запросов в приложении можно строить по разному, использование REST-принципов, а именно, анализ вида запроса и content negotiation в дополнение к разбору адреса наиболее универсально по сравнению с традиционной системой routes а-ля Rails первых версий и URL patterns в Django, например. Ну то есть под универсальностью понимается минимум ограничений в системе роутинга, как-то так.
а как вам идея диспетчеризации на основе компонентов url?
Вот пример, может и не особо удачный, но идея я думаю понятна — осуществлять роутинг лишь по адресной строке.
Вот пример, может и не особо удачный, но идея я думаю понятна — осуществлять роутинг лишь по адресной строке.
Прошу прощения, Ваш текст бегло глянул, может отвечу не в тему. Если диспетчеризация основывается только на основе компонент url, главный недостаток в том, что это в некотором смысле противоречит сути HTTP, в котором action — это вид запроса, а не часть URL, то есть URL определяет представление ресурса, а не действие с ним.
Соответственно, получаем более логичную, простую, а главное, стандартную схему адресов, соответствующих структуре представляемой информации, а не действиям над ней. С практической точки зрения — все компоненты приложения единообразны, не нужно придумывать сложных шаблонов адресов, структуру приложения легко формализовать, проще интегрировать приложения с внешними инструментами, например, различными JS-фреймворками.
Соответственно, получаем более логичную, простую, а главное, стандартную схему адресов, соответствующих структуре представляемой информации, а не действиям над ней. С практической точки зрения — все компоненты приложения единообразны, не нужно придумывать сложных шаблонов адресов, структуру приложения легко формализовать, проще интегрировать приложения с внешними инструментами, например, различными JS-фреймворками.
возможно,… — то есть большинство фреймворков противоречит сути HTTP?
Просто длительное время все считали HTTP чисто транспортным протоколом, в то время как его создатели мыслили гораздо шире. А потом до всех вдруг ДОПЕРЛО :) Собственно, культа из этого делать не надо, пусть цветут все цветы, скажем REST часто противопоставляется XML-RPC и SOAP для веб-сервисов, но это специализированные решения для собственно RPC, а REST — универсален.
Что до противоречия сути HTTP — так до сих пор и с PUT и DELETE не все умеют работать по человечески, приходится имитировать через POST, со временем оно, конечно, устаканится.
Что до противоречия сути HTTP — так до сих пор и с PUT и DELETE не все умеют работать по человечески, приходится имитировать через POST, со временем оно, конечно, устаканится.
НЛО прилетело и опубликовало эту надпись здесь
Для DELETE дополнительный параметр будет в самый раз, поскольку это по сути одна операция, просто с дополнительным сайд-эффектом :) Дополнительные действия могут быть представлены как вложенный ресурс, поддерживающий операцию POST, при этом не может иметь подресурсов.
То есть, скажем, есть запись блога /entries/1231/, поддерживающая GET, PUT, DELETE. Предположим, я хочу, чтобы за запись голосовали. Создается вложенный ресурс /entries/1231/vote/, поддерживающий только метод POST, в котором и реализуется операция голосования. При этом логика сохраняется — вы действительно создаете новый голос, просто его никто снаружи не видит :) Для DELETE пример в голову не приходит — DELETE — он и в Африке DELETE :)
На эту тему можно найти много информации, например, по запросу REST design patterns есть масса всего полезного. На меня кстати в свое время произвела большое впечатление презентация автора RoR: Discovering a World Of Resources, очень хорошая, хотя система REST-диспетчеризации в RoR мне не очень нравится.
То что стандартным линком можно только GET — это правильно, стандартные линки ссылаются на различные представления. Если надо что-то другое — то это уже не линк, а форма, стилизованная под линк. К тому же если действия выполняются по GET, есть шанс, что случайно зашедший поисковик порушит всю цивилизацию :)
То есть, скажем, есть запись блога /entries/1231/, поддерживающая GET, PUT, DELETE. Предположим, я хочу, чтобы за запись голосовали. Создается вложенный ресурс /entries/1231/vote/, поддерживающий только метод POST, в котором и реализуется операция голосования. При этом логика сохраняется — вы действительно создаете новый голос, просто его никто снаружи не видит :) Для DELETE пример в голову не приходит — DELETE — он и в Африке DELETE :)
На эту тему можно найти много информации, например, по запросу REST design patterns есть масса всего полезного. На меня кстати в свое время произвела большое впечатление презентация автора RoR: Discovering a World Of Resources, очень хорошая, хотя система REST-диспетчеризации в RoR мне не очень нравится.
То что стандартным линком можно только GET — это правильно, стандартные линки ссылаются на различные представления. Если надо что-то другое — то это уже не линк, а форма, стилизованная под линк. К тому же если действия выполняются по GET, есть шанс, что случайно зашедший поисковик порушит всю цивилизацию :)
что-то я не понял, а можно выполнить несколько разнородных операций за одно обращение?
поправьте меня, если я ошибаюсь, вы предлагаете убрать традиционную абстракцию, наложенную поверх HTTP?
поправьте меня, если я ошибаюсь, вы предлагаете убрать традиционную абстракцию, наложенную поверх HTTP?
Можно ли вызвать одновременно две функции за один вызов? Можно, если объединить их вызовы в новую функцию. Вроде как применимо не только к REST.
По поводу абстракции — я не предлагаю, я пользуюсь тем, что предложили более умные люди, а именно, рассматривать HTTP не как транспортный протокол, а как протокол приложения, он получается вполне достаточен для этого. Собственно меня даже в первую очередь привлекает удобная с точки зрения написания и суппорта архитектура приложения, и уже потом все остальное (stateless, которой иногда даже, о ужас, можно пожертвовать, например).
По поводу абстракции — я не предлагаю, я пользуюсь тем, что предложили более умные люди, а именно, рассматривать HTTP не как транспортный протокол, а как протокол приложения, он получается вполне достаточен для этого. Собственно меня даже в первую очередь привлекает удобная с точки зрения написания и суппорта архитектура приложения, и уже потом все остальное (stateless, которой иногда даже, о ужас, можно пожертвовать, например).
А как реализовать GET запросы из JS, отправляющие (а не только получающие) данные удаленному веб приложению (кросс доменный запрос) через JSONP? К примеру виджет, который получает информацию от пользователей сайтов использующих этот виджет? А использование POST при работе с некоторыми формами(вставляющими информацию) не всегда лучшее решение. Так не стоит делать, например, когда необходимо сохранить возможность навигации средствами браузера.
Ну, в одном ресурсе может быть сколько угодно методов с различными именами и шаблонами URL, обрабатывающих GET. GET-параметры тоже никто не отменял, так что вроде как заводим соответствующие методы и вперед, если я правильно понял ваш вопрос. Cледование концепции не самоцель, собственно, в этом же синтаксисе можно описать обычный любезный всем URL-matching, просто вписав в маску HTTP сочетание GET|POST.
В презентации к семинару есть упоминание behaviour ресурса, но описания что это и как работает так и не нашел. Хотелось бы узнать об этом по подробнее.
И все таки по моему вы изобрели велосипед. Сравните с системой Route во фреймворке Kohana 3 — kerkness.ca/wiki/doku.php?id=routing:routing_basics
В PHP велосипедостроение — стиль жизни, увы. Что касается Kohana — оно же вроде HTTP-методы не различает, то есть там чистый матчинг адресов, или я не прав? Если прав — то это немного другой велосипед :)
Зато, кстати, описание Kohana заставило вспомнить еще один момент, который в статье не освещен, а именно — обратная генерация адресов. Вобще говоря, хорошо, когда адреса внутри приложения не прописываются явно, а единообразно генерируются, это дает возможность при необходимости малой кровью их поменять. Конечно, замена адресов конечных ресарсов маловероятна, однако, например, вынесение отдельных подкаталогов первого уровня на отдельные поддомены — запросто.
Так вот, многие фреймворки используют описание схемы не только для прямого матчинга URL → метод, но и для обратного — для генерации адресов. В нашем случае наличие сублокаторов создает проблему, так как вообще говоря, поведение сублокаторов зависит от факторов, не учитываемых в описании схемы. Есть и еще одно соображение — ссылок надо генерить много, поэтому процесс генерации должен быть максимально простым. Мы решаем эту проблему не особенно красиво — для приложения пишется примитивный класс-генератор адресов, предельно простой и не связанный со схемой приложения. Соответственно, при изменении схемы может понадобиться скорректировать и этот класс, не очень удобно, зато быстро и просто.
Зато, кстати, описание Kohana заставило вспомнить еще один момент, который в статье не освещен, а именно — обратная генерация адресов. Вобще говоря, хорошо, когда адреса внутри приложения не прописываются явно, а единообразно генерируются, это дает возможность при необходимости малой кровью их поменять. Конечно, замена адресов конечных ресарсов маловероятна, однако, например, вынесение отдельных подкаталогов первого уровня на отдельные поддомены — запросто.
Так вот, многие фреймворки используют описание схемы не только для прямого матчинга URL → метод, но и для обратного — для генерации адресов. В нашем случае наличие сублокаторов создает проблему, так как вообще говоря, поведение сублокаторов зависит от факторов, не учитываемых в описании схемы. Есть и еще одно соображение — ссылок надо генерить много, поэтому процесс генерации должен быть максимально простым. Мы решаем эту проблему не особенно красиво — для приложения пишется примитивный класс-генератор адресов, предельно простой и не связанный со схемой приложения. Соответственно, при изменении схемы может понадобиться скорректировать и этот класс, не очень удобно, зато быстро и просто.
Да, там идет regexp относительно url.
Но основная проблема REST — HTML не позволяет отправить иной запрос к серверу, кроме GET и POST. Поддержка других методов будет в HTML5 и XHTML2.
Хотя не спорю, за REST будущее, но пока основная область его использования — межсерверные запросы ( хотя могу и ошибаться )
Но основная проблема REST — HTML не позволяет отправить иной запрос к серверу, кроме GET и POST. Поддержка других методов будет в HTML5 и XHTML2.
Хотя не спорю, за REST будущее, но пока основная область его использования — межсерверные запросы ( хотя могу и ошибаться )
PUT и DELETE имитируются через POST одинаково практически во всех фреймворках (через _method). С точки зрения построения приложения это в любом случае не хуже, чем кодировать delete где-нибудь в URL или в POST-параметре, что, собственно, эквивалентно.
Из скриптовых серверных фреймворков по крайней мере RoR (см. world of resources) и web.py практически чистый REST. Не похоже, чтобы на них писали только веб-службы. Из клиентских фреймворков REST из коробки в ExtJs и Dojo как минимум, это тоже не межсерверные запросы.
ну, в Symfony например есть объект запроса sfRequest
не пиши на пхп
Где можно найти исходники вашего фреймворка? На DevConf вы сказали, что он OpenSource.
Интересно, как вы реализовали регулярные выражения с именованными параметрами.
Интересно, как вы реализовали регулярные выражения с именованными параметрами.
Я нашел класс для работы с регулярными выражениями, но не понял как вы обрабатываете именованные параметры.
Посмотрите тут:
github.com/techart/tao-base/blob/master/lib/WS/REST/URI.php
класс WS.REST.URI.Template.
github.com/techart/tao-base/blob/master/lib/WS/REST/URI.php
класс WS.REST.URI.Template.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Слой контроллера веб-приложения на основе архитектуры REST