Вы путаете два разных запроса. Обращаю ваше внимание на пример, который Вас заинтересовал — это пример расширения функциональности это сервиса! В этом случае контроль полученных параметров осуществляется в самой реализации расширения.
Для вставки записи/записей самим сервисом нужно указать другой URL запроса .../data/table/rs.users. В этом случае сервис генерирует SQL запрос по полученным параметрам, выполнение которого при указанной опечатке в имени поля завершиться с ошибкой.
В заинтересовавшем Вас примере указан URL .../data/query/TestQuery.insert.
Совершенно верно, универсальный. Пример, который Вас заинтересовал — это пример реализации расширения функциональности сервиса. Контроль параметров в этом случае обеспечивается самой реализацией этого расширения.
Контроль значения поля можно добавить в явном виде, например так
if (us_last == null) throw new RestException("RST0100E", new Object[] {"us_last"}, lang);
И все же настаиваю, что куда угодно задеплоить не получиться! Вас в "куда угодно" могут просто не пустить. Предложат Вам передать дистрибутив для самостоятельного деплоя "куда угодно", куда Вы не имеете доступа.
Непременно познакомлюсь. Но из наличие SCDF вовсе не вытекает, что мое решение хуже. Каждое решение разрабатывается под определенные задачи.
Мое направленно на уменьшение кодирования и гибкости при эксплуатации (тут уже описывал, более подробно расписывать не буду).
Предложенное решение позволяет разрабатывать приложения как "обычные" (эксплуатируемые на одном узле) любого назначения, но которое может быть трансформировано в многоузловую систему без изменения программного кода вашего "обычного" приложения. Для этого достаточно изменить конфигурацию приложения. Добавление в систему избыточных узлов позволяет превратить вашу "обычное" приложение в отказоустойчивую систему опять же без модификации вашего кода, опять же достаточно изменить конфигурацию вашего приложения.
Предложенное решение позволяет горизонтально масштабировать ваше приложение без модификации вашего кода, при этом масштабирование будет практически линейным (если пренебречь потерями на сеть при передаче данных между узлами). Нагрузку между узлами можно разделить практически равномерно — снимаются метрики с каждой функции. Понятно, что нагрузка на ту или иную функциональность системы со временем изменяется и то что поделено на текущих данных статистики 50 на 50 завтра может показать распределение нагрузки, например, 40 на 60.
Предложенное решение позволяет разрабатывать собственные кластерные приложения — опять же любого назначения.
Такой гибкостью не обладают ни одна из перечисленных вами технологий.
Втащили в рассуждение "левое ПО" (кеш), которое не имеет какого либо отношения
к рассмотренным протоколом и реагирующее на содержание HTTP заголовка. Естественно, разная реакция этого кеша на разное содержание HTTP заголовка Вам дает разный результат в независимости от протокола. Ваши выводы не корректны. Да еще и минусы ставите, нехорошо.
Единственное различие между GET и POST это объем передаваемых серверу данных — GET имеет ограничение в 4К. Всё! А уж что "спрятано" на стороне сервера — это уже зависит от реализации. И GET-ом можно модифицировать состояние сервера.
Почему в статье рассмотрено использования для RCP метода POST, а для REST метода GET? Ведь все зависит от реализации. Можно ведь и перевернуть примеры статьи — в REST использовать POST, а в RCP GET. И тогда все рассуждения в статье "посыпятся".
Я думаю, что большое количество коммуникаций в команде все же следствие. Первопричина такого положения в выборе технологий и решений для реализации на основании первичного понимания решаемой задачи. Естественно стараются выбрать технологии и решения, которые позволяют наиболее "быстро" и с "меньшими" затратами удовлетворить потребности заказчика.
Первичное понимание задачи часто бывает не полным и поверхностным. Выбранные технологии и решения на основе этого первичного понимания в дальнейшем могут не удовлетворять новому осознанию потребностей заказчика (при погружении в предметную область). Довольно часто начинаю придумывать различные "обходные решения". С течением времени таких "обходных решений" становиться все больше и больше, что объективно подталкивает к все большим коммуникациям внутри команды. Коммуникаций становиться все больше, реализации программного кода все меньше. Делать модификацию и наращивать функциональность становиться все сложнее. Добавление дополнительных ресурсов практически не изменяет ситуацию.
Чтобы этого избежать, нужно задавать себе хотя бы один вопрос. Какие полезные свойства добавит та или иная технология или решение в ваш проект? Именно добавит свойства в ваш проект, а не какими "полезными" свойствами они обладают. От части "полезных" свойств выбранной технологии или решения Вы можете сознательно отказаться и, более того, еще потратить усилия и ресурсы для этого отказа (применить "обходное решение").
Оцените каждое "полезное" свойство выбираемой технологии или задачи. Например, нужен ли в вашей задаче какой то кеш? Большинство скажет, да — нужен. Кеш ускоряет работу программы. Хорошо. А в ОС есть кеш? Есть. В СУБД есть кеш? Есть. И зачем Вам еще один кеш? Нет, нам надо. У нас предполагается высокая загрузка. Хорошо. Все ли ваши запросы потребуют кеширования? Нет. Можете ли сейчас предсказать какие запросы потребуют кеширования? В большинстве случаев, нет. А кешем надо как то управлять? Надо. А существуют ли другие решения ускоряющие обработку часто повторяющихся запросов? Существуют. Так зачем Вам еще один кеш?
Или еще одно "полезное" свойство — автоматическая перезагрузка вашего кода при его изменениях. В эксплуатации это свойство нужно? На мой взгляд, нет. Ваша система может "молотить" годами, если бы не потребность обслуживания железа и ОС. Ну и зачем тащить это "полезное" свойство в систему?
Или увидели, вот это свойство такого то решения будет востребовано в вашей системе. Хорошо. А другие свойства полезны? Нет. Так стоит ли тащить это решение в вашу систему? Может быть лучше повторить это решение в собственной реализации? Получите желаемое свойства вашей системе "заточенное" под ваши требования.
Так что думаете, оценивайте свой выбор и потребности решаемой задачи. И, возможно, сможете избежать проблемы описанной в статье.
инициализацию всех объектов на основании конфигурационного файла
транспортный уровень приложения (вынесен на уровень конфигурации приложения)
модель MVFA, которая позволяет преобразовывать "обычное" приложение в многоузловое масштабируемое отказоустойчивое распределенное приложение с функциями восстановления после сбоев (с некоторыми оговорками конечно), в том числе кластерные, просто изменением конфигурации приложения.
ничем не ограничивает ваши потребности при разработке и эксплуатации приложения
позволяет экономить различные ресурсы (финансовые, трудовые, эксплуатационные и т.д.)
мониторинг, экземпляры объектов "функция" мониторится по периодам, по их методам собирается статистика с момента запуска приложения
позволяет стоить сложные иерархические программные модели приложения, "приложения" могут обращаться ко множеству "функций" и выступать в качестве "функции" для других объектов "приложения".
Вы можете собирать свое приложение из различных "кубиков", гибко реагируя на возникающее требования. Можно переопределять или наследовать, дополняя новыми свойствами, поведение любой функции в процессе эксплуатации.
не туда ответил
Тот же самый запрос без использования расширения
Запрос:
Ответ: (HTTP Status 400)
Сгенерированный SQL запрос и возникшая ошибка (из лога без стека вызовов)
Вы путаете два разных запроса. Обращаю ваше внимание на пример, который Вас заинтересовал — это пример расширения функциональности это сервиса! В этом случае контроль полученных параметров осуществляется в самой реализации расширения.
Для вставки записи/записей самим сервисом нужно указать другой URL запроса .../data/table/rs.users. В этом случае сервис генерирует SQL запрос по полученным параметрам, выполнение которого при указанной опечатке в имени поля завершиться с ошибкой.
В заинтересовавшем Вас примере указан URL .../data/query/TestQuery.insert.
Сервис генерирует запрос по полученным параметрам, параметра us_last нет в параметрах запроса, а запрос
INSERT INTO rp.users (us_name, us_lat, us_email) VALUES (?, ?, ?)
выполнится с ошибкой
Возникнет ошибка выполнения SQL запроса с сообщением, что поле us_lat не существует.
Совершенно верно, универсальный. Пример, который Вас заинтересовал — это пример реализации расширения функциональности сервиса. Контроль параметров в этом случае обеспечивается самой реализацией этого расширения.
Контроль значения поля можно добавить в явном виде, например так
if (us_last == null) throw new RestException("RST0100E", new Object[] {"us_last"}, lang);
см метод inset класса TestQuery.java
И все же настаиваю, что куда угодно задеплоить не получиться! Вас в "куда угодно" могут просто не пустить. Предложат Вам передать дистрибутив для самостоятельного деплоя "куда угодно", куда Вы не имеете доступа.
Непременно познакомлюсь. Но из наличие SCDF вовсе не вытекает, что мое решение хуже. Каждое решение разрабатывается под определенные задачи.
Мое направленно на уменьшение кодирования и гибкости при эксплуатации (тут уже описывал, более подробно расписывать не буду).
Прежде всего гибкостью.
Предложенное решение позволяет разрабатывать приложения как "обычные" (эксплуатируемые на одном узле) любого назначения, но которое может быть трансформировано в многоузловую систему без изменения программного кода вашего "обычного" приложения. Для этого достаточно изменить конфигурацию приложения. Добавление в систему избыточных узлов позволяет превратить вашу "обычное" приложение в отказоустойчивую систему опять же без модификации вашего кода, опять же достаточно изменить конфигурацию вашего приложения.
Предложенное решение позволяет горизонтально масштабировать ваше приложение без модификации вашего кода, при этом масштабирование будет практически линейным (если пренебречь потерями на сеть при передаче данных между узлами). Нагрузку между узлами можно разделить практически равномерно — снимаются метрики с каждой функции. Понятно, что нагрузка на ту или иную функциональность системы со временем изменяется и то что поделено на текущих данных статистики 50 на 50 завтра может показать распределение нагрузки, например, 40 на 60.
Предложенное решение позволяет разрабатывать собственные кластерные приложения — опять же любого назначения.
Такой гибкостью не обладают ни одна из перечисленных вами технологий.
*
предложенное решение отличается от перечисленных вами.
Втащили в рассуждение "левое ПО" (кеш), которое не имеет какого либо отношения
к рассмотренным протоколом и реагирующее на содержание HTTP заголовка. Естественно, разная реакция этого кеша на разное содержание HTTP заголовка Вам дает разный результат в независимости от протокола. Ваши выводы не корректны. Да еще и минусы ставите, нехорошо.
Если для Вас и это не ограничения, тем более не понятны ваши рассуждения в статье. Сравните POST в обоих случаях.
Единственное различие между GET и POST это объем передаваемых серверу данных — GET имеет ограничение в 4К. Всё! А уж что "спрятано" на стороне сервера — это уже зависит от реализации. И GET-ом можно модифицировать состояние сервера.
Почему в статье рассмотрено использования для RCP метода POST, а для REST метода GET? Ведь все зависит от реализации. Можно ведь и перевернуть примеры статьи — в REST использовать POST, а в RCP GET. И тогда все рассуждения в статье "посыпятся".
Я думаю, что большое количество коммуникаций в команде все же следствие. Первопричина такого положения в выборе технологий и решений для реализации на основании первичного понимания решаемой задачи. Естественно стараются выбрать технологии и решения, которые позволяют наиболее "быстро" и с "меньшими" затратами удовлетворить потребности заказчика.
Первичное понимание задачи часто бывает не полным и поверхностным. Выбранные технологии и решения на основе этого первичного понимания в дальнейшем могут не удовлетворять новому осознанию потребностей заказчика (при погружении в предметную область). Довольно часто начинаю придумывать различные "обходные решения". С течением времени таких "обходных решений" становиться все больше и больше, что объективно подталкивает к все большим коммуникациям внутри команды. Коммуникаций становиться все больше, реализации программного кода все меньше. Делать модификацию и наращивать функциональность становиться все сложнее. Добавление дополнительных ресурсов практически не изменяет ситуацию.
Чтобы этого избежать, нужно задавать себе хотя бы один вопрос. Какие полезные свойства добавит та или иная технология или решение в ваш проект? Именно добавит свойства в ваш проект, а не какими "полезными" свойствами они обладают. От части "полезных" свойств выбранной технологии или решения Вы можете сознательно отказаться и, более того, еще потратить усилия и ресурсы для этого отказа (применить "обходное решение").
Оцените каждое "полезное" свойство выбираемой технологии или задачи. Например, нужен ли в вашей задаче какой то кеш? Большинство скажет, да — нужен. Кеш ускоряет работу программы. Хорошо. А в ОС есть кеш? Есть. В СУБД есть кеш? Есть. И зачем Вам еще один кеш? Нет, нам надо. У нас предполагается высокая загрузка. Хорошо. Все ли ваши запросы потребуют кеширования? Нет. Можете ли сейчас предсказать какие запросы потребуют кеширования? В большинстве случаев, нет. А кешем надо как то управлять? Надо. А существуют ли другие решения ускоряющие обработку часто повторяющихся запросов? Существуют. Так зачем Вам еще один кеш?
Или еще одно "полезное" свойство — автоматическая перезагрузка вашего кода при его изменениях. В эксплуатации это свойство нужно? На мой взгляд, нет. Ваша система может "молотить" годами, если бы не потребность обслуживания железа и ОС. Ну и зачем тащить это "полезное" свойство в систему?
Или увидели, вот это свойство такого то решения будет востребовано в вашей системе. Хорошо. А другие свойства полезны? Нет. Так стоит ли тащить это решение в вашу систему? Может быть лучше повторить это решение в собственной реализации? Получите желаемое свойства вашей системе "заточенное" под ваши требования.
Так что думаете, оценивайте свой выбор и потребности решаемой задачи. И, возможно, сможете избежать проблемы описанной в статье.
Фреймворк предоставляет:
Вы можете собирать свое приложение из различных "кубиков", гибко реагируя на возникающее требования. Можно переопределять или наследовать, дополняя новыми свойствами, поведение любой функции в процессе эксплуатации.
В отличи от Вас, я не ограничен рамками одного узла, моя система работает на множестве узлов и самостоятельно умеет "разбираться" с дефектными узлами.
Пора закругляться. Благодарю за дискуссию.