Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(5) вы путаете тёплое с мягким. https - это надстройка над http, которая живёт только на уровне веб сервера. На уровне сервера приложений трафик уже расшифрованный.
Выбор get/post/других http-глаголов должен быть обусловлен семантикой и логикой запроса, а "плохостью"
Выбор get/post/других http-глаголов должен быть обусловлен семантикой и логикой запроса, а "плохостью"
(5)
Не соглашусь с вами насчет проблем безопасности GET запросов
Каждый запрос клиента к серверу должен содержать всю информацию, необходимую для выполнения этого запроса, без хранения какого-либо контекста на стороне сервера. Состояние сеанса целиком хранится на стороне клиента.
Надо просто правильно проектировать API
Не соглашусь с вами насчет проблем безопасности GET запросов
Каждый запрос клиента к серверу должен содержать всю информацию, необходимую для выполнения этого запроса, без хранения какого-либо контекста на стороне сервера. Состояние сеанса целиком хранится на стороне клиента.
Надо просто правильно проектировать API
(5) На то это и пример, не понимаю претензии. Платформа 1С не отвечает за протокол, а разработчику 1С вообще без разницы что стоит перед/на веб-сервере. Об этом должны заботиться сетевики, безопасники, админы.
Про GET - можете ссылкой о чем речь? Делать запрос на получение ресурса в REST API методом POST - звучит странно.
Про GET - можете ссылкой о чем речь? Делать запрос на получение ресурса в REST API методом POST - звучит странно.
(37) почему многие в комментариях так активно "цепляются" за подачу? Англицизмы, написано не русскими буквами - это все что беспокоит профессионала в наше время? Есть термины, которые придуманы не нами, есть песни, перевод которых никого не интересует.
(42)
людям проще сказать КГ/АМ
Людям действительно проще так сказать, даже, предположу, Вам. Так что не провоцируйте людей - будьте к ним благосклонны. Они же пришли с утра на работу и вся их активность часто ограничивается поиском того, над кем бы постебаться. Такова жизнь большинства наших (и не наших - тоже) сограждан, увы и ах...
(9) в зипе cf файл с двумя подсистемами самого инструмента и доработками по примеру из статьи. ЛогированиеREST и ОбработкаВызоваREST это название общих модулей. Так же, в самом начале статьи есть ссылка на репозиторий гитхаб, где базовая конфигурация лежит как проект EDT.
За разработку темы трассировки + и sm.
По содержанию статьи
* "ключевым отличием от него является способ заключения контракта" - не понял какие именно отличия?
* указан что выбран "Elastic APM", но нет описания что вообще возможно собирать в трассировки и почему выбрали именно его. В модуле
Сам разбирал структуру сообщения sentry, много чего интересного накопал, блок с производительностью там тоже есть.
* для многих развернуть сервис мониторинга неподъемная задача, нужна как минимум ссылка на документацию по установке.
* По каким аспектам пересекается с анализом производительности БСП?
* Возможно ли переложить эти наработки на мониторинг работы внутренних функций, в формах например?
По коду
* зачем комментарий?
Зачем выделять в отдельную переменную?
Хардкод системы мониторинга
Отправка сделана синхронно, и если сервер мониторинга недоступен, то колом встает основной сервис. Возможно коллеги предложат решения с + и -.
По реализации
У Валерия Крынина уровень абстракции сложен для восприятия (мне по крайней мере), у вас представлена более простая модель HTTP сервиса с одной точкой входа, думаю подходы будут интересны сообществу, например вариант маршрутизации без regexp
* в ПроверитьКонтекстЗапросаПоСпецификации не увидел блока валидации тела запроса по JSON Schema наработки уже есть.
На сколько сложно вынести описание обработчиков в код?
Его все равно версионировать, что из БД доп. затраты по сравнению с кодом. И прослеживаемость "Выполнить" отсутствует
По содержанию статьи
* "ключевым отличием от него является способ заключения контракта" - не понял какие именно отличия?
* указан что выбран "Elastic APM", но нет описания что вообще возможно собирать в трассировки и почему выбрали именно его. В модуле
ДобавитьВТелоЗапросаМетаданные(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаТранзакцию(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаИнтервалы(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаМетрики(ТелоЗапроса, КонтекстЗамера);
ДобавитьВТелоЗапросаОшибки(ТелоЗапроса, КонтекстЗамера);
Сам разбирал структуру сообщения sentry, много чего интересного накопал, блок с производительностью там тоже есть.
* для многих развернуть сервис мониторинга неподъемная задача, нужна как минимум ссылка на документацию по установке.
* По каким аспектам пересекается с анализом производительности БСП?
* Возможно ли переложить эти наработки на мониторинг работы внутренних функций, в формах например?
По коду
* зачем комментарий?
// ОписаниеСервиса
ОписаниеСервиса = УправлениеRESTПовтИсп.ПолучитьОписаниеСервиса(КонтекстЗапроса.КлючСервиса);
Зачем выделять в отдельную переменную?
в СформироватьДанныеКонтекстаЗапроса()
ИмяПубликации = ПолучитьИмяПубликации(ДанныеИсходногоЗапроса);
Результат.ИмяПубликации = ИмяПубликации;
Хардкод системы мониторинга
HTTPСоединение = Новый HTTPСоединение("vm-ais-logmonitor.technodom.kz", 8200);
Отправка сделана синхронно, и если сервер мониторинга недоступен, то колом встает основной сервис. Возможно коллеги предложат решения с + и -.
По реализации
У Валерия Крынина уровень абстракции сложен для восприятия (мне по крайней мере), у вас представлена более простая модель HTTP сервиса с одной точкой входа, думаю подходы будут интересны сообществу, например вариант маршрутизации без regexp
* в ПроверитьКонтекстЗапросаПоСпецификации не увидел блока валидации тела запроса по JSON Schema наработки уже есть.
На сколько сложно вынести описание обработчиков в код?
// Вызов обработчика
РезультатОбработчика = Неопределено;
Команда = "РезультатОбработчика = " + КонтекстЗапроса.ОписаниеМетода.Обработчик + "(КонтекстЗапроса, КонтекстЗамера);";
Попытка
Выполнить(Команда);
Его все равно версионировать, что из БД доп. затраты по сравнению с кодом. И прослеживаемость "Выполнить" отсутствует
(16) ух как много вопросов. На каждый развернуто тут не ответишь, предлагаю перейти в личку, а ещё лучше в телегу.
Если кратко, касательно кода - представлен не готовый продукт, об этом сразу сказано. Там многое стоит ещё доделать, в том числе валидация и упрощение жизни разработчику. Путь на сервер APM да, забыл исправить) А вот про обработчики не понял вопроса.
Если кратко, касательно кода - представлен не готовый продукт, об этом сразу сказано. Там многое стоит ещё доделать, в том числе валидация и упрощение жизни разработчику. Путь на сервер APM да, забыл исправить) А вот про обработчики не понял вопроса.
(19) А вот про обработчики не понял вопроса. - сейчас реализовано в виде записей с справочниках, мне привычнее в виде кода, возможно просто непривычно. При наличии "библиотеки" HTTP сервиса под нее можно сделать трансформацию кода в/из swagger.
"На каждый развернуто тут не ответишь" - задал в том числе чтобы коллеги обратили внимание на эти вопросы.
Моя версия была опубликована в 19 году, Валерий в 20 году добавил свое, после началась "движуха" по swagger, в этом году вроде еще "пролетала" реализация. Движение есть, вероятность сделать серверную часть на уровне Коннектор1С присутствует. Нужен тот кто соберет базово github проект, дальше могу подхватить, практика EDT+git полезна, пример
Рядом тема с JSON-RPC, как легковесная замена SOAP, больше ограничений по сравнению с REST, но и реализация думаю проще будет.
"На каждый развернуто тут не ответишь" - задал в том числе чтобы коллеги обратили внимание на эти вопросы.
Моя версия была опубликована в 19 году, Валерий в 20 году добавил свое, после началась "движуха" по swagger, в этом году вроде еще "пролетала" реализация. Движение есть, вероятность сделать серверную часть на уровне Коннектор1С присутствует. Нужен тот кто соберет базово github проект, дальше могу подхватить, практика EDT+git полезна, пример
Рядом тема с JSON-RPC, как легковесная замена SOAP, больше ограничений по сравнению с REST, но и реализация думаю проще будет.
(22)
Я выше арифметики не подымаюсь....
Я выше арифметики поднимаюсь только при решении тестовых задач на очередных собеседованиях. Но там вся математика сводится к тому, как интерпретировать формулу. Остальное - это много арифметики, ибо даже красивый значок суммы - это всего лишь сложение элементов массива.
(32) Тебе смешно, а у меня - комплексы... Как почитаю тексты... осмелюсь сказать, коллег и слюна прокисает от досады. Люди работают с какими-то небожителями, решают какие-то их удивительные и выдающиеся проблемы. А я вспоминаю лица своих заказчиков, у которых основные проблемы описываются на уровне средней группы детсада. Такое ощущение, что я в каком-то интеллектуальном гетто оказался, без права на подъем с глубины.
"один из сервисов внутри компании"
Внутри компании лучше SOAP. Там и с типизацией получше, с валидацией и структура данных документирована.
Про одну точку входа вообще загадка. Она по определению у одного HHTP-сервиса одна. В чем прикол парсить URL, вместо того, чтобы добавить шаблон и тем самым задокументировать функцию? Не? Пусть в модуле копают и выяснят, чего там как работает.
Это кунг-фу с разбором строк, когда на уровне платформы все можно получить разжеванным, оно зачем? У вас модуль обработки вшит в конфигурацию. Вы все-равно не сможете просто так добавить обработку другого запроса.
Внутри компании лучше SOAP. Там и с типизацией получше, с валидацией и структура данных документирована.
Про одну точку входа вообще загадка. Она по определению у одного HHTP-сервиса одна. В чем прикол парсить URL, вместо того, чтобы добавить шаблон и тем самым задокументировать функцию? Не? Пусть в модуле копают и выяснят, чего там как работает.
Это кунг-фу с разбором строк, когда на уровне платформы все можно получить разжеванным, оно зачем? У вас модуль обработки вшит в конфигурацию. Вы все-равно не сможете просто так добавить обработку другого запроса.
(25) Условно не соглашусь. Не отрицаю наличие такой ситуации, когда система 1С интегрирована с "устаревшими" продуктами, в период создания которых SOAP действительно являлся стандартом. Но сейчас даже http REST это уже не "модно", все больше grpc и другого низкоуровневого стека используется.
(28) Я программирование начинал изучать как раз у немцев (промышленные контроллеры только начинали появляться). И вот какое отличие заметил уже тогда (1989 - 1990). Их "учителя" не стараются умничать. Они отчетливо понимают, что их аудитория признает свою изначальную некомпетентность и пришла именно за знаниями и компетенциями, а не на замер.... кто там чем хотел померяться! Если взять несколько самоучителей по программированию отечественных и забугорных авторов, то отчетливо видно, что западенец пишет, как комикс для детей, зачастую - с картинками! Его задача - обучить, дать понимание. Ему не нужно раздувать свое эго, если он реально дожил до самоуважения к себе, как к профессионалу. И берем учебники (методические материалы) наших авторов. На первых же строках автор просто обязан продемонстрировать свое знание высшей математики и истории партии с решениями последних съездов) Текст пресыщен кучей научных терминов, за ссылками на которые надо постоянно нырять "в зад" книжке. Не чтение, а мучение.
Среди коллег, увы, такая родимая генетическая линия тоже присутствует. Надо так написать, чтобы был виден "уровень"))
Среди коллег, увы, такая родимая генетическая линия тоже присутствует. Надо так написать, чтобы был виден "уровень"))
(29) Вот соглашусь с Вами, хотя и не стал бы говорить, что наши учебники так уж плохи. Я начал изучать программирование лет в 10-11 по книжке, которую взял у друга. Книжка наша, про бейсик. Потом у приятеля взял книжку "Паскаль в иллюстрациях" - офигенная книжка, в которой все эти "дискретные алгебры" с их графами и двоичными деревьями, хеш-функциями и прочими оптимизациями работы со списками, даны были в виде картинок и очень простых текстов. Но фундаментальное понимание программирования я именно по "нашей" книжке без картинок получил, т.е. сам по себе ответ на вопрос "как это работает". Да, потребовалось выплакать тонну слез, рассчитывать было совершенно не на кого, ибо в 1990-м году вокруг не было компьютеров, а программистов не было даже на большом расстоянии. И я сейчас нисколько не жалею, что мне тогда пришлось пережить эту дыру боли, и очень рад, что я взломал тот текст, а не он меня - сработал принцип образования по Занкову, когда перед учеником ставится такая задача, которую он заведомо не может решить, и через которую единицы продираются. Это действительно работает - на своей шкуре проверил.
(30) это далеко не SOAP. Сейчас тренд в сторону уменьшения размера пакета данных и, соответственно, трафика. Ведь одной из причин появления формата JSON было именно этим обусловлено. Хотя история циклична, команды переходят на protobuff, который по сути низкоуровневый SOAP =)
(35)
А SOAP - он же любой массив данных может передать - хоть жуткий и большой XML, хоть сжатый в 100 раз массив данных в base64. "Протобуф" просто избавляется от дополнительных байт base64 и заголовков полей, но он работает только поверх HTTP2.
А в части моего коммента, то если добавить то, о чем я написал, будет реализация SOAP на JSON. Ну да, пакеты будут чуть меньше, но сложность реализации возрастает. При том для кейсов с 1С размер пакетов - это второстепенная проблема.
Сейчас тренд в сторону уменьшения размера пакета данных
Ну так смысл этого тренда в том, что клиентов очень много стало, а пропускная способность сети за ними не успевает.
А SOAP - он же любой массив данных может передать - хоть жуткий и большой XML, хоть сжатый в 100 раз массив данных в base64. "Протобуф" просто избавляется от дополнительных байт base64 и заголовков полей, но он работает только поверх HTTP2.
А в части моего коммента, то если добавить то, о чем я написал, будет реализация SOAP на JSON. Ну да, пакеты будут чуть меньше, но сложность реализации возрастает. При том для кейсов с 1С размер пакетов - это второстепенная проблема.
(36) я может что-то не правильно понимаю, но SOAP это протокол и согласно ему сообщение имеет определенную структуру, которую никуда не выкинешь. Как бы мы не сжимали тело сообщения, останется обязательная часть, и именно отход от нее обусловлен постепенным отказом от SOAP в высоконагруженных системах. Плюс каждое движение над телом запроса - это дополнительные "такты" как на клиенте так и на сервере.
(38)
(38)
И да, для SOAP можно написать так: В HTTP придется все это засовывать в тело ответа, т.е. как минимум создавать новый объект "HTTPОтвет" и засовывать в тело ответа получившиеся данные. И если их не паковать, то размер HTTP-пакета будет больше, чем размер пакета SOAP с пожатым хранилищем значений.
останется обязательная часть
Она не такая и большая. И, опять же, в 1С не является узкой частью.
(38)
это дополнительные "такты"
Опять же, в 1С это малосущественно. Я вот, лично, не вспомню и даже навскидку придумать не могу сценарий, где такты и вес сообщения для 1С являются существенными факторами.
И да, для SOAP можно написать так:
Возврат Новый ХранилищеЗначений( Запрос.Выполнить().Выгрузить(), Новый СжатиеДанных(0) );
(43) В частном случае системы 1С как 90% всех ИС компании - да. Но все таки в статье моя основная мысль - система 1С как один из сервисов внутри компании. И вот тут становится вопрос анализа всего архитектурного стека разработки компании. И свои выводы я предоставил.
(44) Ну так у каждой системы есть определенные требования к уровню обслуживания: реакция, доступность, нагрузка. 1С - это бэкофис, в лучшем случае еще что-то типа внешнего хранилища НСИ - этакий провайдер мастер-данных, MDM. В кейсе с MDM доступность системы должна быть высокой, но и пакеты там не особо большие ходят. В части бэкофиса, то 1С - это коллектор поступающих от фронта сообщений. И если думать об архитектуре, то в части MDM просто обязан быть механизм кеширования, чтобы за каждым ежеминутно нужным фронт не таскался в 1С - пусть берет из кеша, а 1С пусть кеш обновляет при изменениях. А при транспорте в коллектор нужен приличный брокер сообщений с гарантированной доставкой, а не прямой HTTP-сервис.
Я вот вообще не вижу 1С, как высокодоступного поставщика данных в корпоративной системе - это не ее функция.
Я вот вообще не вижу 1С, как высокодоступного поставщика данных в корпоративной системе - это не ее функция.
(49)
Мы говорим о разных вещах.
Напротив, мы говорим об одном и том же - об архитектуре. Это слово есть даже в кратком содержании статьи (слово "Архитектор"). Так вот архитектура - это то to be, которое обеспечивает те самые реакцию, доступность и нагрузку. Если нагрузка небольшая, требования к доступности невысокие, а реакция позволяет пользователю сходить и налить кипятка, то нам достаточно 1С и SOAP. Если же требования возрастут, то выигрыш в 10% на HTTP-сервисах не даст ничего, т.к. все упрется сначала в доступность, потом в нагрузку, а потом и в реакцию (ну или наоборот, сначала в реакцию, потом в нагрузку, а за ними и в доступность, ибо Вы решили обновить систему в самый неподходящий момент, ибо предыдущее обновление все к хренам сломало).
(50) Сожалею, но вы меня так и не поняли. Статья - интеграция с точки зрения архитектора. Человек, принимающий решение на основании своих компетенций и поставленных условий решения задачи. А условия не всегда про техническую составляющую, а больше про денежную. В данной ветке дискуссии мне больше нечего добавить =)
Я не уверен, что паттерн Front Controller такое уж хорошее решение - при всех плюсах получаем серьезные проблемы:
1. Единую точку отказа - любая ошибка в самом методе (а иногда и в вызываемых из него) приведет к остановке всех сервисов.
Либо к тому, что они будут работать не так, как ожидалось (это в огород "попытка исключение", или заплатке типа Если ИСТИНА Или ...).
Не забываем, что "в подарок" еще получаем единую точку атаки.
Это все равно как отказ автопилота полностью заблокирует возможность ручного управления самолетом.
Мне кажется, что реализация такого паттерна без обязательной реализации системы "аварийного" канала - плохое решение.
2. Искусственная связь разных сущностей с "навязанным" общим решением.
Например, считаем, что все действия надо логировать, потом передумываем, точка входа начинает проверят некие условия и вместо удобства выполняет никому не нужные действия. Плюс еще на этапе архитектуры приходится закладывать соответствующие возможности, усложняя ее.
А все потому, что логика разных сущностей меняется независимо от остальных и с разной скоростью.
3. Потенциал стать бутылочным горлышком. Это хорошо видно на примере типовых конфигураций 1С, когда движения делаются путем вызова стандартных методов, которые зачастую выполняют 90% не нужной работы, в угоду универсальности и в ущерб понятности и быстродействию.
4. Как тут уже написали - вместо набора понятных и независимых сущностей, получаем некую загадочную "точку входа", куда по любому чиху лезем, чтобы понять что она умеет. И лезть в документацию, в общем случае, - плохая идея, т.к. совпадение документации с реальной жизнью, такое себе, красивое.
1. Единую точку отказа - любая ошибка в самом методе (а иногда и в вызываемых из него) приведет к остановке всех сервисов.
Либо к тому, что они будут работать не так, как ожидалось (это в огород "попытка исключение", или заплатке типа Если ИСТИНА Или ...).
Не забываем, что "в подарок" еще получаем единую точку атаки.
Это все равно как отказ автопилота полностью заблокирует возможность ручного управления самолетом.
Мне кажется, что реализация такого паттерна без обязательной реализации системы "аварийного" канала - плохое решение.
2. Искусственная связь разных сущностей с "навязанным" общим решением.
Например, считаем, что все действия надо логировать, потом передумываем, точка входа начинает проверят некие условия и вместо удобства выполняет никому не нужные действия. Плюс еще на этапе архитектуры приходится закладывать соответствующие возможности, усложняя ее.
А все потому, что логика разных сущностей меняется независимо от остальных и с разной скоростью.
3. Потенциал стать бутылочным горлышком. Это хорошо видно на примере типовых конфигураций 1С, когда движения делаются путем вызова стандартных методов, которые зачастую выполняют 90% не нужной работы, в угоду универсальности и в ущерб понятности и быстродействию.
4. Как тут уже написали - вместо набора понятных и независимых сущностей, получаем некую загадочную "точку входа", куда по любому чиху лезем, чтобы понять что она умеет. И лезть в документацию, в общем случае, - плохая идея, т.к. совпадение документации с реальной жизнью, такое себе, красивое.
(48) Для меня описанные проблемы выглядят немного "притянутыми за уши":
1. Единая точка входа - это изолированная функциональность подсистемы и отлично поддается тестирования. Если допускается возможность попадания в прод такого рода ошибок в коде - это проблема другого характера. А ошибка разработчика, написавшего обработчик метода сервиса, всегда изолирована через попытку и не может привести к остановке всего сервиса.
2. Цель применения подобного паттерна - разделение ответственности и единообразность. И если мы говорим разработчику не логировать что-то внутри сервиса почему он должен начать это делать? Или почему мы вдруг решим отойти от паттерна и в контроллер тянуть какие-то условия, нарушая тем самым его смысл?
3. Не вижу как пример с типовыми коррелирует с предоставленным подходом? Есть общепринятые рамки создания REST API и не предвидится никаких "вдруг" изменений в механизм его работы.
4. Сошлюсь на ответ в пункте 3. И вопрос к вам от меня - что является "набором понятных и независимых сущностей"?
1. Единая точка входа - это изолированная функциональность подсистемы и отлично поддается тестирования. Если допускается возможность попадания в прод такого рода ошибок в коде - это проблема другого характера. А ошибка разработчика, написавшего обработчик метода сервиса, всегда изолирована через попытку и не может привести к остановке всего сервиса.
2. Цель применения подобного паттерна - разделение ответственности и единообразность. И если мы говорим разработчику не логировать что-то внутри сервиса почему он должен начать это делать? Или почему мы вдруг решим отойти от паттерна и в контроллер тянуть какие-то условия, нарушая тем самым его смысл?
3. Не вижу как пример с типовыми коррелирует с предоставленным подходом? Есть общепринятые рамки создания REST API и не предвидится никаких "вдруг" изменений в механизм его работы.
4. Сошлюсь на ответ в пункте 3. И вопрос к вам от меня - что является "набором понятных и независимых сущностей"?
(52)
Если бы я знал "как надо", я бы не комментарии писал,а статьи :)
Просто имеем единый метод, любая непредвиденная ошибка в котором приведет к тому что все встанет.
При этом "вес\значимость" того, что этот метод делает может быть различным для разных, вызываемых им методов.
И ошибка эта вовсе необязана выглядеть как "все пропало", она может провиться, например, чт овремя отклика станет слишком велико.
Если я не путаю, то в качестве примера часто приводят браузеры, но если один из них перестанет работать, всегда можно вызвать другой.
ПолучитьСписокСкладов - понятно и никак не зависит от "УдалитьСклад".
"УдалитьСклад" - понятный и независимый от метода "ПолучитьСписокСкладов", потому как идентификатор склада я могу получить множеством других способов.
Если бы я знал "как надо", я бы не комментарии писал,а статьи :)
Просто имеем единый метод, любая непредвиденная ошибка в котором приведет к тому что все встанет.
При этом "вес\значимость" того, что этот метод делает может быть различным для разных, вызываемых им методов.
И ошибка эта вовсе необязана выглядеть как "все пропало", она может провиться, например, чт овремя отклика станет слишком велико.
Если я не путаю, то в качестве примера часто приводят браузеры, но если один из них перестанет работать, всегда можно вызвать другой.
"набором понятных и независимых сущностей"
ПолучитьСписокСкладов - понятно и никак не зависит от "УдалитьСклад".
"УдалитьСклад" - понятный и независимый от метода "ПолучитьСписокСкладов", потому как идентификатор склада я могу получить множеством других способов.
(33) По ссылке - "GraphQL это синтаксис, который описывает как запрашивать данные", а RPC - " класс технологий, позволяющих программам вызывать функции или процедуры в другом адресном пространстве". Инструменты для разного класса задач. Про RPC упоминаю потому что на практике периодически вижу SOAP с схемой данных в виде одной строки в которую упихивают все подряд (XML), которое нормально заменяется JSON-RPC.
(59)
описывает как запрашивать данные
А что мы делаем при вызове веб-сервисов? В основном или запрашиваем данные, или передаем данные в систему. Остальные кейсы малозначимы. gpaphQL - это просто еще один механизм, позволяющий запросить тот пакет данных, который нужен получателю. Это как oData, фактически, только для извлечения данных.
(58) "Просто имеем единый метод, любая непредвиденная ошибка в котором приведет к тому что все встанет." - если у вас косяк в коде и он не интерпретируется на уровне модуля HTTP сервиса, то даже в ЖР не напишет, не важно его количество.
Либо маршрутизация делается на уровне платформы, но она не умеет в regexp, и за ней "допроверять" в коде, либо используем роутер реализованный кодом. Проблемы при маршрутизации на уровне платформы начнутся когда начнете добавлять Listeners (слушатели), типовых форматов ответов, валидации передаваемых данных, доп аутентификации итд, вам придется в каждую функцию обработчик их прописывать, пробовал, неудобно.
"Если я не путаю, то в качестве примера часто приводят браузеры, но если один из них перестанет работать, всегда можно вызвать другой." - сначала надо написать чтобы было удобно поддерживать и окружающим была понятна структура. Для примера посмотрите HTTP сервис для Mango в УНФ/РарусCRM, при адаптации их переписал на более прозрачную схему.
Для отказоустойчивости нужно разделить зоны ответственности, код маршрутизации отвечает только за маршрутизацию и подключаемых слушателей переданную ему из функции модуля HTTP сервиса, их может быть более одного.
@botokash поэтому писал что хочу делать кодом, чтобы не завязываться на общую структуру данных в спр.
Либо маршрутизация делается на уровне платформы, но она не умеет в regexp, и за ней "допроверять" в коде, либо используем роутер реализованный кодом. Проблемы при маршрутизации на уровне платформы начнутся когда начнете добавлять Listeners (слушатели), типовых форматов ответов, валидации передаваемых данных, доп аутентификации итд, вам придется в каждую функцию обработчик их прописывать, пробовал, неудобно.
"Если я не путаю, то в качестве примера часто приводят браузеры, но если один из них перестанет работать, всегда можно вызвать другой." - сначала надо написать чтобы было удобно поддерживать и окружающим была понятна структура. Для примера посмотрите HTTP сервис для Mango в УНФ/РарусCRM, при адаптации их переписал на более прозрачную схему.
Для отказоустойчивости нужно разделить зоны ответственности, код маршрутизации отвечает только за маршрутизацию и подключаемых слушателей переданную ему из функции модуля HTTP сервиса, их может быть более одного.
@botokash поэтому писал что хочу делать кодом, чтобы не завязываться на общую структуру данных в спр.
(61)
Думаю понял теперь о чем вы хотели сказать. Я считаю это вопросом в плоскости реализации и не вижу его таким значимым по отношению к поставленной цели, описанной в статье. Я реализовал то что почитал более быстрым, а другой разработчик может сделать как ему больше нравится. Напомню, цель моей статьи была не конечный продукт, а демонстрация практики и подхода к разработке сервисов =)
чтобы не завязываться на общую структуру данных в спр
Думаю понял теперь о чем вы хотели сказать. Я считаю это вопросом в плоскости реализации и не вижу его таким значимым по отношению к поставленной цели, описанной в статье. Я реализовал то что почитал более быстрым, а другой разработчик может сделать как ему больше нравится. Напомню, цель моей статьи была не конечный продукт, а демонстрация практики и подхода к разработке сервисов =)
(61)
Вот, собственно я это и имел в виду, но, написал коряво. Тогда уже получаем достаточную надежность.
Просто насторожило введение Front Controller без оговорки об опасности реализации его в лоб, ну, или я был не внимателен.
А если надо больше, то это уже можно реализовать на уровне перенаправления средствами Apache + кластеризация и т.п., далее много умных слов, не имеющих никакого отношения к статье. :)
P.S. А вообще, было бы интересно, если кто-нибудь подробно осветил только правильную реализация данного паттерна в 1С, как раз с учетом первичной отказоустойчивости и балансировки нагрузки хотя бы по слушателям.
Для отказоустойчивости нужно разделить зоны ответственности, код маршрутизации отвечает только за маршрутизацию и подключаемых слушателей переданную ему из функции модуля HTTP сервиса, их может быть более одного.
Вот, собственно я это и имел в виду, но, написал коряво. Тогда уже получаем достаточную надежность.
Просто насторожило введение Front Controller без оговорки об опасности реализации его в лоб, ну, или я был не внимателен.
А если надо больше, то это уже можно реализовать на уровне перенаправления средствами Apache + кластеризация и т.п., далее много умных слов, не имеющих никакого отношения к статье. :)
P.S. А вообще, было бы интересно, если кто-нибудь подробно осветил только правильную реализация данного паттерна в 1С, как раз с учетом первичной отказоустойчивости и балансировки нагрузки хотя бы по слушателям.
(64) "то это уже можно реализовать на уровне перенаправления средствами Apache" -
"балансировки нагрузки хотя бы по слушателям." - вывод аутентификации на уровень кода, создание нескольких публикаций для одного HTTP сервиса, балансировка на уровне NGINX
нужно разбираться что за сервис, какого типа нагрузка, какое количество запросов, если есть состояние сеанса, то рядом нужно redis например прикручивать. Если "справочники", то выношу в промежуточный сервис на PostgREST, статью по этому поводу писал.
Будет свободное время - попробую организовать проект на GitHub и в него собирать наработки.
"балансировки нагрузки хотя бы по слушателям." - вывод аутентификации на уровень кода, создание нескольких публикаций для одного HTTP сервиса, балансировка на уровне NGINX
нужно разбираться что за сервис, какого типа нагрузка, какое количество запросов, если есть состояние сеанса, то рядом нужно redis например прикручивать. Если "справочники", то выношу в промежуточный сервис на PostgREST, статью по этому поводу писал.
Будет свободное время - попробую организовать проект на GitHub и в него собирать наработки.