Почитал RFC и готов с вами согласиться (хотя POST тоже может создавать ресурс, но это не основное его применение). До этого, честно говоря, ориентировался на менее официальную литературу (блоги и книги). Большое спасибо за замечание!
Принципы RESTful вообще ничего не говорят об HTTP, если уж на то пошло, как, впрочем, и оригинальная диссертация Роя Филдинга (даже в части, касающейся HTTP).
Применение DELETE и PUT является скорее стандартом де-факто (по крайней мере, я не знаю официальной документации ни на REST, ни на применение REST over HTTP).
Ничего не копировал и не знаю, что именно я не понял.
Про ваш п.1 я написал следующее:
Обратите внимание на тот факт, что спецификация HTTP не обязывает сервер понимать все методы (которых на самом деле гораздо больше, чем 4) — обязателен только GET
Про п. 2 я тоже писал: HTML 4.01 не позволяет писать в форме иные методы, кроме GET и POST, но во всех основных браузерах вы можете отправить XMLHttpRequest любым методом из как минимум GET/POST/DELETE/PUT. Так что этого вашего возражения я тоже не понял.
В общем случае, действительно, весьма сложно реализовать PUT/DELETE запросы, тем не менее, решения есть (как я уже писал, есть XMLHttpRequest, есть решения на PHP, на Ruby on Rails (там это вообще нативно поддерживается) и на многих других платформах).
При том, что я люблю и уважаю REST, не могу с вами согласиться. Первое упоминание о REST датируется 2000 годом, а более-менее применяться он начал вообще два-три года назад.
Если будет не только быстрее и эффективнее разрабатывать, но и проще поддерживать, то я присоединюсь к вам :) Только я ни разу не видел подобных проектов длиннее 500 строк. Хотя, возможно, они и имеют право на жизнь.
Метод DELETE означает, намерение клиента удалить какой-либо ресурс, но сервер может ему это не позволить (например, если удаление невозможно в принципе или если у клиента нет прав). То есть DELETE /user/theRavel ничем не хуже с точки зрения безопасности, чем GET /user/theRavel/delete
Не знаю, за что вас заминусовали, но вопрос в любом случае поставлен неверно: проблема не в том, что HTML не поддерживает REST, а в том, что HTML не позволяет отправить иной запрос к серверу, кроме GET и POST. Поддержка других методов будет в HTML5 и XHTML2.
Отличное замечание! Действительно, если у нас уже есть файл с таким именем, то мы получим то же самое значение дайджеста и два файла будут иметь одну и ту же ссылку. Значит, в третьей части заодно рассмотрим решение этой проблемы.
Что касается ваших альтернатив: я писал на C#, RoR и немного на Python. Субъективно мне больше нравится RoR (из-за обилия удобных мелочей при разработке), но C# (видимо, вы говорите об ASP.NET) — тоже очень и очень хорош, особенно в последних версиях. Про Python мне судить сложно, так как я не работал с Django (а это основной способ разработки веб-приложений на пайтоне). Вообще Ruby и Python во многом похожи с точки зрения синтаксиса (но пайтон работает быстрее).
Посоветовать вам что-либо довольно сложно: все три альтернативы весьма хороши (но если это вам важно, то бесплатный софт для разработки проще раздобыть для RoR и пайтона — хорошая Visual Studio стоит больших денег). C#, пожалуй, посложнее для новичка будет, но не в разы. В общем, выбирайте либо наугад, либо по тому же принципу, что и дистрибутив линукса — тот, который знает кто-либо из ваших хороших друзей (чтобы мог давать советы).
Возвращаясь к вашему мнению о rails: посмотрите, например, на сайты play-me.ru, carzzz.ru, linkfeed.ru — все они написаны на RoR, но у них мало общего с тем же BaseCamp. В общем, я не вижу каких-либо ограничений на разнообразии сайтов.
Про шаблонизатор: верстальщик может работать только с шаблонами (и не трогать другие файлы вообще), но иногда хочется повторяющийся HTML-код вынести в отдельные методы; верстальщик может писать одно и то же несколько раз, а может, действительно, написать вспомогательный метод (не в шаблоне, а в отдельном файле, доступном сразу всем шаблонам), который облегчит его работу. Не знаю, как эта проблема решена в Perl, но полагаю, что примерно так же. Но в базе хранить HTML не прийдется никогда.
Пример вспомогательного метода:
def user_link(id)
"<a href='/users/#{id}'>Пользователь</a>"
end
Мне тоже не очень понятно, что значит «однообразные сайты», но проблем с разнообразием сайтов я не встречал. Касательно шаблонизатора — ни в коем случае не считаю стандартный Erb убогим (у него есть проблемы с производительностью на действительно сложных шаблонах), но ничего не мешает подключить Haml-шаблонизатор, который работает значительно быстрее. Верстальщику для полноценной натяжки верстки необходимо немного (в пределах трех-четырех часов изучения) знать Ruby (уметь написать if и for) — в остальном там чистых HTML.
Мне, кажется, пока еще рановато: приложение еще не готово для полноценного использования (и дело не только в рюшечках, но и в важных аспектах безопасности). После третьей статьи обязательно выложу.
Применение DELETE и PUT является скорее стандартом де-факто (по крайней мере, я не знаю официальной документации ни на REST, ни на применение REST over HTTP).
Про ваш п.1 я написал следующее:
Про п. 2 я тоже писал: HTML 4.01 не позволяет писать в форме иные методы, кроме GET и POST, но во всех основных браузерах вы можете отправить XMLHttpRequest любым методом из как минимум GET/POST/DELETE/PUT. Так что этого вашего возражения я тоже не понял.
Еще раз спасибо за внимательность.
Что касается ваших альтернатив: я писал на C#, RoR и немного на Python. Субъективно мне больше нравится RoR (из-за обилия удобных мелочей при разработке), но C# (видимо, вы говорите об ASP.NET) — тоже очень и очень хорош, особенно в последних версиях. Про Python мне судить сложно, так как я не работал с Django (а это основной способ разработки веб-приложений на пайтоне). Вообще Ruby и Python во многом похожи с точки зрения синтаксиса (но пайтон работает быстрее).
Посоветовать вам что-либо довольно сложно: все три альтернативы весьма хороши (но если это вам важно, то бесплатный софт для разработки проще раздобыть для RoR и пайтона — хорошая Visual Studio стоит больших денег). C#, пожалуй, посложнее для новичка будет, но не в разы. В общем, выбирайте либо наугад, либо по тому же принципу, что и дистрибутив линукса — тот, который знает кто-либо из ваших хороших друзей (чтобы мог давать советы).
Возвращаясь к вашему мнению о rails: посмотрите, например, на сайты play-me.ru, carzzz.ru, linkfeed.ru — все они написаны на RoR, но у них мало общего с тем же BaseCamp. В общем, я не вижу каких-либо ограничений на разнообразии сайтов.
Про шаблонизатор: верстальщик может работать только с шаблонами (и не трогать другие файлы вообще), но иногда хочется повторяющийся HTML-код вынести в отдельные методы; верстальщик может писать одно и то же несколько раз, а может, действительно, написать вспомогательный метод (не в шаблоне, а в отдельном файле, доступном сразу всем шаблонам), который облегчит его работу. Не знаю, как эта проблема решена в Perl, но полагаю, что примерно так же. Но в базе хранить HTML не прийдется никогда.
Пример вспомогательного метода:
def user_link(id) "<a href='/users/#{id}'>Пользователь</a>" endМне тоже не очень понятно, что значит «однообразные сайты», но проблем с разнообразием сайтов я не встречал. Касательно шаблонизатора — ни в коем случае не считаю стандартный Erb убогим (у него есть проблемы с производительностью на действительно сложных шаблонах), но ничего не мешает подключить Haml-шаблонизатор, который работает значительно быстрее. Верстальщику для полноценной натяжки верстки необходимо немного (в пределах трех-четырех часов изучения) знать Ruby (уметь написать if и for) — в остальном там чистых HTML.