Взаимодействие веб-сервисов через REST

[@Foxcool]

for (my $id = 0; $id <= 10; $id++) — калька с си. В случае с Perl лучше подойдет

for (1..10) {
$downloads->[$_] =
{ 'id' => $_,
…
}
}

А руби код у вас перемешался так или правда у языка такой синтаксис?

[@Foxcool]

for (1..10) {
    $downloads->[$_] = {
        'id' => $_,
        …
        }
    }

[@sobereagle]

Спасибо за совет! Исправил.

Что касается синтаксиса Ruby, то здесь самого Ruby очень мало. Этот «перемешанный» код, что мы видим — строковое представление объектов. Он не должен быть «красивым», это просто демонстрация возможности получения таких объектов со стороны Perl.

[@perl_demon]

>Perl сам по себе, без модулей, очень ограниченный инструмент.

Ни в коем случае не ради холивара, просто мне не понятно что именно Вы имели в виду под этой фразой? И что такое «Perl без модулей»?

[@xoma]

ага, мне тоже интересно какой язык без модулей не является ограниченным? Если только PHP, у которого все в «ядре», а модулей как таковых нет вообще =)

[@BlessMaster]

PEAR с PECL почили в бозе? )))

[@xoma]

А в них есть что-то стоящее =)?
Есть надежда на Composer, но он еще молод и зелен, старикашечка CPAN рвет его как сами знаете кого =)

[@BlessMaster]

Не поверите

[@xoma]

А что можете предложить в таком случае по моей проблеме andrey.opeykin.ru/blog/2012/06/29/brat-vsya-sila-v-modulyax/?

[@BlessMaster]

Вы просто ставите акцент на то, что ВСЁ должно быть где-то в каком-то едином репозитории. Здесь Вы правы — в PHP такого явления нет и вероятно никогда не будет. Бардак и демократия — полностью в духе коммьюнити :-)
Я же эту точку зрения на необходимость чего-то единого — не разделяю. Весь нужный в моём проекте код находится в моём проекте — с конкретной версией, с которой проект протестирован, возможно даже с моими патчами, которым скорее всего нечего делать в оригинальном продукте. Исключение — модули PECL, которые нужно компилить.
Но всё это имеет мало отношения к тому, с чего началось обсуждение — наличие модулей и наличие в PEAR/PECL чего-то полезного.

[@xoma]

Нет ну как же мало… как раз таки не мало. У меня была конкретная зада — парсить почту от разных получателей и я не смог найти хорошего модуля для PHP, хотя для Perl нашел за 5 минут. Вам не приходилось решать такую задачу (я про парсинг)? Может порекомендуете какой-то модуль?

[@BlessMaster]

Я не использую чужие модули таким образом. Обычно идёт значительный оверхед, поскольку пишется на все случаи жизни.
Я нахожу подходящий модуль или похожий проект, смотрю как он реализован и реализую в контексте своей задачи. В крайнем случае включаю в свой проект нужные мне классы — как-то так оно получается.
Разумеется, есть исключения — вроде того же geoip, который можно использовать только как цельное дополнение к движку php, либо такие вещи как фреймворки — если проект построен на ZF — там уже в комплекте столько всего, что искать что-то ещё обычно не приходится. ZF вообще некоторые называют «PEAR для Enterprise».
Так что, можно посмотреть в сторону Zend Framework или Symphony — там очень много всего и многие комоненты можно использовать отдельно, не внедряя фреймворк в свой проект целиком.

[@russum]

Perl никак не является ограниченным, упомянутый в статье Mojolicious написан на чистом перле (т.е. все что входит в стандартную поставку перла любых версий (после 5.10) и ни одного дополнительного модуля на любых ОС). А функциональность Mojolicious просто огроменная…

[@enej]

ActiveResource в рельсах начиная со второй версии.

[@Renius]

У rails по дефолту был нормальный механизм REST-взаимодействия. С самых ранних версий scaffold был RESTfull. Только в версии 1.0 было не все так хорошо.
После версии 1.0 было писать на рельсах только RESTfull приложения, всегда. «Покажи мне свой routes.rb, и я скажу кто ты» — шутка 2007-го года про непонимающих REST. Версия rails была 1.2 уже рестфул.
ActiveResource::Base заработало так как вы описываете в версии 2.0 в декабре 2007 года.

[@amikhailov]

В Rails 4 уже убрали поддержу ActiveResource, он теперь будет жить отдельно