Комментарии 14
А можно поподробней про
Пoчему REST «история», чем Вы решили его заменить и почему Ваше решение лутче?
REST мы забудем (он уже история) и напишем что-то вроде Google AdWords API, со своим SQL like запросником?
Пoчему REST «история», чем Вы решили его заменить и почему Ваше решение лутче?
Наверно для справочников и CRUD он подойдет, но если чуть дальше, то начинается отсебятина сплошная.
К примеру выполнять фильтрацию крайне не удобно, мне нужно получить все договора где долг по нему больше, меньше, либо равен чему-то. Для этого GET параметры не подойдут, нужен POST и маппинг, или отдельный метод под фильтрацию, а это уже не REST. Или параметров много и они не влезают в GET, тоже делаем POST и в итоге получаем, что реальный REST только для CRUD примитивных операций, все остальное работает по своему. Или отдача постраничная: в REST я на GET должен вернуть массив Entity, как мне вернуть список страниц и другую мета инфу, не нарушая правил, тоже делаем свою отсебятину. А если мне нужны не все поля, а только некоторые, тоже придумываем какой-то параметр.
А если еще все параметры маппить в контроллере Spring MVC, то декларация метода превращается в ужас. Не проще ли использовать какой-то более вменяемый API, в котором уже все это предусмотрено для любой сущности
К примеру выполнять фильтрацию крайне не удобно, мне нужно получить все договора где долг по нему больше, меньше, либо равен чему-то. Для этого GET параметры не подойдут, нужен POST и маппинг, или отдельный метод под фильтрацию, а это уже не REST. Или параметров много и они не влезают в GET, тоже делаем POST и в итоге получаем, что реальный REST только для CRUD примитивных операций, все остальное работает по своему. Или отдача постраничная: в REST я на GET должен вернуть массив Entity, как мне вернуть список страниц и другую мета инфу, не нарушая правил, тоже делаем свою отсебятину. А если мне нужны не все поля, а только некоторые, тоже придумываем какой-то параметр.
А если еще все параметры маппить в контроллере Spring MVC, то декларация метода превращается в ужас. Не проще ли использовать какой-то более вменяемый API, в котором уже все это предусмотрено для любой сущности
К примеру выполнять фильтрацию крайне не удобно, мне нужно получить все договора где долг по нему больше, меньше, либо равен чему-то. Для этого GET параметры не подойдут, нужен POST и маппинг, или отдельный метод под фильтрацию, а это уже не REST.
С каких пор POST — это уже не REST? Да и в приведенном Вами примере вполне можно составить GET-запрос.
ну давайте начнем с того, что предполагает REST:
1. Правило для постраения URL: к примеру /client, /client/{id}, /client/{id}/invoice
2. HTTP методы имет определенное значение по отношению к ресурсу.
GET — к ресурсу возвращает список записей
GET — ресурс/{id} — конкретную запись
POST/PUT к ресурсу — создает запись
PUT к конкретному ресурс/{id} — изменяет запись
Да по моему примеру можно составить запрос, безусловно, только срашненько выглядеть он будет. Так вот, если нужна фильтрация сложная мы будем делать "/client/filter" какой-нибудь который будет POST, и так для каждого ресурса. В если отказать от этого и сказать. Ресурсов нет — есть сервисы, каждый сервис поддерживает команды, get, query, mutate, запросы всегда идут через POST. Метод get принимает Selector. В котором описываются все фильтры, Paging в котором offset, limit и так далее. Метод query принимает SQL — like зпрос. Метод mutate — …
Для такого рода API клиентская библиотека пишется единжды, серверная тоже, и главное не нужно ничего переписывать если вдруг нужно фильтровать по еще одному полю, все строго структурировано и единообразно, чем не альтернатива?
1. Правило для постраения URL: к примеру /client, /client/{id}, /client/{id}/invoice
2. HTTP методы имет определенное значение по отношению к ресурсу.
GET — к ресурсу возвращает список записей
GET — ресурс/{id} — конкретную запись
POST/PUT к ресурсу — создает запись
PUT к конкретному ресурс/{id} — изменяет запись
Да по моему примеру можно составить запрос, безусловно, только срашненько выглядеть он будет. Так вот, если нужна фильтрация сложная мы будем делать "/client/filter" какой-нибудь который будет POST, и так для каждого ресурса. В если отказать от этого и сказать. Ресурсов нет — есть сервисы, каждый сервис поддерживает команды, get, query, mutate, запросы всегда идут через POST. Метод get принимает Selector. В котором описываются все фильтры, Paging в котором offset, limit и так далее. Метод query принимает SQL — like зпрос. Метод mutate — …
Для такого рода API клиентская библиотека пишется единжды, серверная тоже, и главное не нужно ничего переписывать если вдруг нужно фильтровать по еще одному полю, все строго структурировано и единообразно, чем не альтернатива?
Какой ад все-таки творится в Java-мире. За последний десяток лет придумали несколько новых языков, работащих на старой доброй Java, но с другим синтаксисом — вполне лаконичным, красивым и удобным. Но вот эти адовые XML-конфиги в начале статьи… Неужели это тот путь, которым нужно идти в этом тысячелетии? Есть ощущение, что для некоторых небольших проектов, конфиги будут больше чем сам исходный код на Scala.
Есть путь — SBT, Gradle. Они оба заслуживают внимания, но я попытался использовать более менее привычные инструменты намеренно. Сразу и очень много всего нового не всегда хорошо, может отпугнуть
Если есть возможность, расскажите в следующих статьях о них. Думаю, это будет хорошим дополнением: рассказывая о новых эффективных языках, Вы также раскроете и новые эффективные средства сборки, которые больше отвечают философии этих языков.
Иногда бывает необходимость написать небольшой скрипт на чем-то быстром — Java-family подошла бы вполне, но все эти ужасные Maven'ы после мира скриптовых языков вроде Python или Ruby нагоняют тоску.
Иногда бывает необходимость написать небольшой скрипт на чем-то быстром — Java-family подошла бы вполне, но все эти ужасные Maven'ы после мира скриптовых языков вроде Python или Ruby нагоняют тоску.
рекомендую взглянуть на Play Framework он использует для сборки sbt и достаточно прост в использовании
www.playframework.com/
www.playframework.com/
Простите, но «вы отлично пишете на Java на Scala». Вы пытаетесь переехать вместе со стенами, не надо так.
Почти в каждом посте про Scala, есть такой камент.
И меня всегда удивлял такой подход. Что это вообще значит «на Java на Scala»? Мы же не в секте какой-то.
Напомню, для тех кто на бронетехнике, Scala это мультипарадигменный язык. Это значит, что можно писать как простой ООП код, так и зубодробительную функциональщину.
В примерах приведен простой ООП подход. Ну зачем, скажите мне, везде пихать навороченную функциональщину, на которую способна Scala? Ну в Java вы же не пишете все на дженериках или интерфейсах, только потому что они там есть? А если вдруг увидели простой класс без дженериков, не говорите многозначительно «На Java на C»?..
Сами создатели языка разделяют разработчиков на 2 категории. Создатели библиотек/фреймворков и прикладные программисты.
Вот для фреймворков подходы разработки свои, там и проявляется вся мощь языка. А на прикладном уровне это не так ярко выражается. К тому же, на прикладном уровне работают разного уровня разработчики. Код, приведенный в примерах может понять и начинающий разработчик на Scala. Мало того понять, он и писать сможет. А в реальных проектах это не маловажный факт.
Ну не получится сесть и моментом начать писать все в Scala стиле. А такой подход он вполне хорошо подходит для переезда или добавления Scala в существующий проект.
И меня всегда удивлял такой подход. Что это вообще значит «на Java на Scala»? Мы же не в секте какой-то.
Напомню, для тех кто на бронетехнике, Scala это мультипарадигменный язык. Это значит, что можно писать как простой ООП код, так и зубодробительную функциональщину.
В примерах приведен простой ООП подход. Ну зачем, скажите мне, везде пихать навороченную функциональщину, на которую способна Scala? Ну в Java вы же не пишете все на дженериках или интерфейсах, только потому что они там есть? А если вдруг увидели простой класс без дженериков, не говорите многозначительно «На Java на C»?..
Сами создатели языка разделяют разработчиков на 2 категории. Создатели библиотек/фреймворков и прикладные программисты.
Вот для фреймворков подходы разработки свои, там и проявляется вся мощь языка. А на прикладном уровне это не так ярко выражается. К тому же, на прикладном уровне работают разного уровня разработчики. Код, приведенный в примерах может понять и начинающий разработчик на Scala. Мало того понять, он и писать сможет. А в реальных проектах это не маловажный факт.
Ну не получится сесть и моментом начать писать все в Scala стиле. А такой подход он вполне хорошо подходит для переезда или добавления Scala в существующий проект.
Суть не в «функциональщина/императивщина». Scala даже более чистый ООП язык чем Java, а ее система типов и такие конструкции как трейты и кейс классы позволяют писать супер-лаконичный и переиспользуемый ООП-код. Разумеется, когда есть необходимость в проихводительности лучше отбросить все сомнения и flatMap'ы, взяться за изменяемые структуры данных и погрузится по локоть в ручное перемешивание битов.
Я же говорю про идеоматичность, как с точки зрения кода, так и используемых библиотек. Вокруг Scala уже успело собраться отличное коммьюнити, которое активно занимается разработкой огромного числа отличных инструментов и библиотек. Все изложенное в статье можно сделать в пару десятков строк кода без единого XML файла'а и Java EE Bean'а на коком-нибудь Play framework, либо даже самостоятельно с помощью связки Spray + Akka.
Я же говорю про идеоматичность, как с точки зрения кода, так и используемых библиотек. Вокруг Scala уже успело собраться отличное коммьюнити, которое активно занимается разработкой огромного числа отличных инструментов и библиотек. Все изложенное в статье можно сделать в пару десятков строк кода без единого XML файла'а и Java EE Bean'а на коком-нибудь Play framework, либо даже самостоятельно с помощью связки Spray + Akka.
По поводу Play Framework или связки Spray + Akka полностью согласен.
Но в использовании привычного многим SpringMVC не вижу каких-то проблем. Это еще один приятный момент в Scala. Можно использовать проверенные библиотеки.
Начальство часто тяжело уломать использовать какой-то Play. Да и на Spring-то часто несогласны, ибо «За покупку IBM еще никого не увольняли» )) А это нормальный вариант, чтобы уж совсем не погрязнуть в Java EE Bean'ах и в тоже время изучить новые технологии.
У меня был проект, где JavaEE писали полностью на Scala, со всеми EE-шными аннотациями и прочими прелестями. Этакий ScalaEE. Только потому, что был продакшен стек, в котором просто нет места всяким (со слов техлида, про Play и Lift) «Хипстерским технологиям». Да и Scala-то попробовать еле уломали. И только после демонстрационного проекта, который ребята пилили на выходных, в надежде глотнуть свежего воздуха со Scala. Ибо JavaEE уже порядочно всех за долбала.
И вполне себе отлично пишется. Хоть и выглядит странно)
Но в использовании привычного многим SpringMVC не вижу каких-то проблем. Это еще один приятный момент в Scala. Можно использовать проверенные библиотеки.
Начальство часто тяжело уломать использовать какой-то Play. Да и на Spring-то часто несогласны, ибо «За покупку IBM еще никого не увольняли» )) А это нормальный вариант, чтобы уж совсем не погрязнуть в Java EE Bean'ах и в тоже время изучить новые технологии.
У меня был проект, где JavaEE писали полностью на Scala, со всеми EE-шными аннотациями и прочими прелестями. Этакий ScalaEE. Только потому, что был продакшен стек, в котором просто нет места всяким (со слов техлида, про Play и Lift) «Хипстерским технологиям». Да и Scala-то попробовать еле уломали. И только после демонстрационного проекта, который ребята пилили на выходных, в надежде глотнуть свежего воздуха со Scala. Ибо JavaEE уже порядочно всех за долбала.
И вполне себе отлично пишется. Хоть и выглядит странно)
Я понимаю вашу точку зрения, но это создает плохую практику «рубки дерева бензопилой». Да, бензопилу в руках держать приятнее — красиво, технологично, но не надо показывать это другим в пример. Пока Scala-коммьюнити преимущественно состоит из «хипстеров» (работающих в крупных интернет компаниях и сильнейших CS-вузах мира, ага (: ) она может позволить себе быстрый рост и изменяемость (хотя уже сейчас начался переход к большей стабильности API и совместимости версий). А если в нее ломанутся Java-разработчики и начнут пытаться руководить балом — язык ожидает стагнация, из-за давнего существования которой в Java разработчики изначально и начинают смотреть в сторону Scala.
перенес
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Меняем Java на Scala. Базовое приложение