такой "такой интерфейс пользователя", напомню — пользователь сам не набирает "волшебные буковки" в строке запроса. Или в ваших системах нет интерфейса пользователя?
Экспорт данных не предусматривает наличие пользователя вообще!
У смены в зоне ответственности может находиться в эксплуатации сотни различных систем. Вы думаете сменный персонал способен понять что означает код 404 в вашей системе?
Вы никогда не сдавали серьезных промышленных систем в эксплуатацию? Вас ни когда не будили ночью или за столом с друзьями для консультации из-за какого ЧП в информационной системе, когда лично Вы заинтересованы дать короткую и ясную консультацию не имея ничего "перед глазами", чтобы вам повторно не перезванивали? На Вас ведь бизнес может повесить ответственность за простой системы, которая может повлечь и финансовые возмещения убытков.
Ответственность за работоспособность информационной системы лежит не на программисте (не на Вас), а на персонале эксплуатирующей организации. И им в первую очередь должно быть понятно как быстро справляться с той или иной проблемой, возникающей в процессе эксплуатации.
Правилом хорошей реализации, считаю наличие документации с описанием кода ошибки, причины (которые, могут приводить к возникновению ошибки с этим кодом) и действий пользователя (обслуживающего персонала), которые устранят эту ошибку. Например, как у IBM
SQL0120N Invalid use of an aggregate function or OLAP function.
Explanation
An aggregate function or OLAP function can only be used in the select list of a fullselect, the having clause, or, with restrictions, in a WHERE clause or GROUP BY clause.
A WHERE clause can contain an aggregate function or OLAP function only if that clause appears within a subquery of a HAVING clause and the argument of the function is a correlated reference to a group.
A GROUP BY clause can contain an aggregate function or OLAP function only if the argument of the function is a correlated reference to a column in a different subselect than the one containing the GROUP BY clause.
An OLAP function cannot be used within the argument list of an XMLQUERY or XMLEXISTS expression.
The statement cannot be processed.
User response
Change the statement so that the aggregate function or OLAP function is not used or used only where it is supported.
sqlcode: -120
sqlstate: 42903
Должно быть ясно всем. И в первую очередь обслуживающему персоналу, которые получат эту информацию от службы поддержки, которой в свою очередь правильно объяснит пользователь причину проблемы.
Через 10 лет Вы вспомните что за "model azure-01" такое и где это вообще?
Это для Вас они тривиальные, а для техподдержки и пользователей — это ничто! Ну скажут они Вам код 404. Далее что будете делать? Где в вашей системе будете искать ошибку по этому информативному коду?
Считаю хорошим примером реализации построение пользовательского интерфейса на основании прав пользователя, что сразу "гасит" ваш вопрос. Дополнительно, доступ к разным функциям, разным таблицам и прочему "разному" можно закрыть ролями настроив соответствующие ограничения в файле web.xml. Гость может выполнить только то, что Вы ему разрешите.
Параметры доступа к БД хранятся на узле сервера приложения. Это может быть тот же узел, где развернут этот сервис или совершенно другой узел.
Пользователь не может выполнить произвольный запрос вообще никак.
Сервис не ограничивает Вас в реализации логики любой сложности. Архитектура движка позволяет Вам вызвать любой код, в том числе и методы этого сервиса на прямую (без REST вызова) как обычный локальный Java код даже с другого узла системы.
Рассмотренный сервис может с ходу работать с любой БД любого производителя поддерживающего JDBC. Ваши примеры, как я понимаю из беглого ознакомления, заточены только на определенные базы. Для сравнения функциональных возможностей требуется гораздо больше времени. Этот сервис можно встроить в любое приложение, например у которого REST сервисы не являются основной функциональностью — для экспорта своих данных в другую систему по запросу.
И что говорит вам это "информативное" сообщение? Не найдено что, ресурс, запись или что то еще? А что скажет это "информативное" сообщение техподдержке, если пользователь передаст ей это сообщение? А если оно прилит Вам от техподдержки — какие выводы Вы по нему сделаете?
Потому что запрошенный URL, если он был удален в вашем сервисе, не будет связан вообще ни с одним вашим ресурсом REST. Этот запрос обработает WEB сервер, который и возвратит этот "мусор". Хорошо, если в него ("мусор") будет включена хоть какая то полезная для Вас информация. А если Вы не сможете найти там внятной информации? А если этот "мусор" без внятной информации получит пользователь, что он должен сообщить в техподдержку — " У меня тут ошибка какая то"?
С "тем же самым" другого варианта быть не может. "Тот же самый" вызывается только как функция расширения универсального сервиса.
Вы задали вопрос, как поведет себя универсальный сервис, если подобная ошибка (опечатка в имени поля) будет допущена при его вызове. Я вам привел ответ на этот вопрос "тот же самый запрос" — вызов через универсальный сервис без расширения функциональности. См. ответ #comment_21245044
такой "такой интерфейс пользователя", напомню — пользователь сам не набирает "волшебные буковки" в строке запроса. Или в ваших системах нет интерфейса пользователя?
Экспорт данных не предусматривает наличие пользователя вообще!
У смены в зоне ответственности может находиться в эксплуатации сотни различных систем. Вы думаете сменный персонал способен понять что означает код 404 в вашей системе?
Вы никогда не сдавали серьезных промышленных систем в эксплуатацию? Вас ни когда не будили ночью или за столом с друзьями для консультации из-за какого ЧП в информационной системе, когда лично Вы заинтересованы дать короткую и ясную консультацию не имея ничего "перед глазами", чтобы вам повторно не перезванивали? На Вас ведь бизнес может повесить ответственность за простой системы, которая может повлечь и финансовые возмещения убытков.
Элементарно
Можно создать VIEW в котором нет поля, которое "не может видеть"
Можно создать класс расширения, который вернет то "что нужно"
Нужно реализовать интерфейс пользователя так, чтобы он мог видеть и делать только то что ему позволено, в зависимости от привилегий пользователя.
Можно использовать 1, 2 и 3 в любом сочетании.
Ответственность за работоспособность информационной системы лежит не на программисте (не на Вас), а на персонале эксплуатирующей организации. И им в первую очередь должно быть понятно как быстро справляться с той или иной проблемой, возникающей в процессе эксплуатации.
Правилом хорошей реализации, считаю наличие документации с описанием кода ошибки, причины (которые, могут приводить к возникновению ошибки с этим кодом) и действий пользователя (обслуживающего персонала), которые устранят эту ошибку. Например, как у IBM
Все зависит от ваших желаний и потребностей и какие бизнес-правила вы хотите соблюсти.
Должно быть ясно всем. И в первую очередь обслуживающему персоналу, которые получат эту информацию от службы поддержки, которой в свою очередь правильно объяснит пользователь причину проблемы.
Через 10 лет Вы вспомните что за "model azure-01" такое и где это вообще?
Это для Вас они тривиальные, а для техподдержки и пользователей — это ничто! Ну скажут они Вам код 404. Далее что будете делать? Где в вашей системе будете искать ошибку по этому информативному коду?
Считаю хорошим примером реализации построение пользовательского интерфейса на основании прав пользователя, что сразу "гасит" ваш вопрос. Дополнительно, доступ к разным функциям, разным таблицам и прочему "разному" можно закрыть ролями настроив соответствующие ограничения в файле web.xml. Гость может выполнить только то, что Вы ему разрешите.
Параметры доступа к БД хранятся на узле сервера приложения. Это может быть тот же узел, где развернут этот сервис или совершенно другой узел.
Пользователь не может выполнить произвольный запрос вообще никак.
Сервис не ограничивает Вас в реализации логики любой сложности. Архитектура движка позволяет Вам вызвать любой код, в том числе и методы этого сервиса на прямую (без REST вызова) как обычный локальный Java код даже с другого узла системы.
Рассмотренный сервис может с ходу работать с любой БД любого производителя поддерживающего JDBC. Ваши примеры, как я понимаю из беглого ознакомления, заточены только на определенные базы. Для сравнения функциональных возможностей требуется гораздо больше времени. Этот сервис можно встроить в любое приложение, например у которого REST сервисы не являются основной функциональностью — для экспорта своих данных в другую систему по запросу.
И что говорит вам это "информативное" сообщение? Не найдено что, ресурс, запись или что то еще? А что скажет это "информативное" сообщение техподдержке, если пользователь передаст ей это сообщение? А если оно прилит Вам от техподдержки — какие выводы Вы по нему сделаете?
В данном случае, формулировка не существенна — HTML "мусор" точно не ожидается.
Что гадать то, проведите эксперимент.
Ваши реализации сервисов то же не все форматы поддерживают. Да и поддерживать все, какой вздумается, в принципе невозможно.
Потому что запрошенный URL, если он был удален в вашем сервисе, не будет связан вообще ни с одним вашим ресурсом REST. Этот запрос обработает WEB сервер, который и возвратит этот "мусор". Хорошо, если в него ("мусор") будет включена хоть какая то полезная для Вас информация. А если Вы не сможете найти там внятной информации? А если этот "мусор" без внятной информации получит пользователь, что он должен сообщить в техподдержку — " У меня тут ошибка какая то"?
Хорошо, прилетит 404 ошибка, но она все равно будет содержать кучу HTML "мусора". И чтобы добраться до "причины" Вам нужно "ковырять" этот "мусор".
Этот сервис вернет 404 ошибку и причину ошибки в том формате, который вы ожидаете.
Совершенно верно, именно удобно. В других реализациях вам прилетит 500 ошибка и куча HTML "мусора", когда Вы ожидаете JSON или XML.
Будет ошибка, как и в любой другой реализации REST сервиса, если в этой реализации "убить" какой то метод.
Реализация сервиса описанная в статье вернет ошибку
"RST0021E" — Имя метода класса генератора SQL запроса не определено.
Правила формирования URI запроса.
.../data/table/… — запрос на модификацию БД через универсальный сервис
.../data/query/… — запрос на модификацию, определенную в методе класса расширения
С "тем же самым" другого варианта быть не может. "Тот же самый" вызывается только как функция расширения универсального сервиса.
Вы задали вопрос, как поведет себя универсальный сервис, если подобная ошибка (опечатка в имени поля) будет допущена при его вызове. Я вам привел ответ на этот вопрос "тот же самый запрос" — вызов через универсальный сервис без расширения функциональности. См. ответ #comment_21245044
Еще есть вопросы?
В ответ #comment_21245044
приведен пример того же самого запроса, без расширения функциональности.
Первый, приведенный в статье, использует расширения функциональности.
Второй, приведенный выше, использует универсальный сервис.
Оба эти запроса выполняют одно и тоже, вставляют одну и ту же запись в таблицу.
Еще остались вопросы?