Консольный редактор это вы сами написали?

У нас есть UI редактор и консольный редактор. Все что руками правится - это набор правил

Оверинженеринг, не?

Ты описываешь правила для конфигов (сам разработчик), а уже наш агент, имея набор правил даёт админу установить возможные значения

Оверинженеринг, не?

Конфиг в открытом виде лежит

> Ты описываешь правила для конфигов Ну вот как-то конфиг подразумевает в себе ручное редактирование. Иначе это уже не конфиг, а структура данных для программы.

Консольный редактор это вы сами написали?

Да

Ручное редактирование - потенциальное место для ошибок!

Мы от этого ушли

Конфиг это что-то, что ты лезешь подправить ручками перед запуском программы, чтобы показать ей как правильно запускаться.

Так и есть, но мы не даём редачить его руками

Ручное редактирование - потенциальное место для ошибок!

Ну да но писать утилиту для редактирования конфига под каждую программу это много больше затрат.

Ты запускаешь или консольную утилиту и говоришь что именно ты хочешь редачить, а он тебе говорит, какие ты туда можешь подставить значения

Или UI, а в нем тоже самое, только в браузере

Чем-то похоже на xml

Там же тоже есть XSD схема, которая определяет формат конфига, а по ней уже можно с автоподстановкой писать реальный xml конфиг

Ну да но писать утилиту для редактирования конфига под каждую программу это много больше затрат.

Не под каждую, а один! А под каждую прогу пишутся только набор правил

конфиг андронного коллайдера?

Не под каждую, а один! А под каждую прогу пишутся только набор правил

А чем тогда это вообще отличается от xml? =)

https://habrahabr.ru/post/90696/

А чем тогда это вообще отличается от xml? =)

Тем, что в простом конфига, можно задать что угодно и валидаторов просто нет

А в нашем случае, прежде чем поменять и сохранить значение - оно валидируется

И это решение себя оправдало

Ошибок конфига просто нет

Подменить его тоже не выйдет

Работает на ура

Хранит в json, чтобы можно было зайти и посмотреть, если сильно хочется. Но вот редачить не выйдет. Отредачишь - он будет не валидный

Можно реализовать и другой драйвер, тогда будет хранить в чем угодно

Мы храним же всегда в json в файле или в консуле...

При такой энтерпрайзной системе вам вообще нет разницы в чем хранить) хоть в binary json, хоть в своем кастомном формате.

Тогда вообще не совсем корректно говорить что вы храните в json, т.к. это только маленькая деталь имплементации вашего механизма конфигов.

Работает на ура

Правильно ли я понимаю, что это просто конфиг? Это не настройка программы, которая выполняется пользователем?

Тоесть это пользуют именно разработчики

И есть сомнение в их внимательности или квалификации

Тогда вообще не совсем корректно говорить что вы храните в json, т.к. это только маленькая деталь имплементации вашего механизма конфигов.

Тут речь шла о формате! А не о системе его редактирования и тому подобное. Я привел наш пример, где в самом формате нам нужны исключительно данные, без комментариев и валидации разметки

Правильно ли я понимаю, что это просто конфиг? Это не настройка программы, которая выполняется пользователем?

Это файл конфигурации, как будет работать приложение

Доступ к БД

Логер

Активность модулей

У простых смертных утилит все эти проблемы с конфигами стоят. И с читаемостью и с корректностью, и с ручным редактированием, и с комментированием.

И с понятностью и с переносимостью.

Тут речь шла о формате! А не о системе его редактирования и тому подобное. Я привел наш пример, где в самом формате нам нужны исключительно данные, без комментариев и валидации разметки

Исключительный случай, как я понял многим нужны комментарии и приятный синтаксис

подобные конфиги - база, логгер и тд, есть у каждого первого, и жалоб на ошибки в конфигах как то не переполняют интернет)

Так что дело именно в формате данных

Исключительный случай, как я понял многим нужны комментарии и приятный синтаксис

Комментарии и описание есть в самом "редакторе", а в файле их нет и, имхо, не должно быть

А где тогда хранятся комментарии?

В редакторе в базе?

Комментарии и описание есть в самом "редакторе", а в файле их нет и, имхо, не должно быть

У вас используется целая система над файлом конфига, для многих случаев это излишне

А где тогда хранятся комментарии?

В конфигурации конфигурации

=)

А визуальный редактор для редактирования конфигов редактора для редактипрования конфигов вы писали?

А визуальный редактор для редактирования конфигов редактора для редактипрования конфигов вы писали?

Да, нечто подобное есть :)

У вас используется целая система над файлом конфига, для многих случаев это излишне

Да

А где тогда хранятся комментарии?

Нет, не в базе. В файле, который описывает правила

У вас используется целая система над файлом конфига, для многих случаев это излишне

Согласен, для большинства случаев это не нужно. Я же просто описал, как это делаем мы.

подобные конфиги - база, логгер и тд, есть у каждого первого, и жалоб на ошибки в конфигах как то не переполняют интернет)

Я привел в пример самое простое. Там конфиг очень большой выходит...

Все перечеслять - достаточно тяжело

И, кстати, имхо проверку конфига должна выполнять программа, иначе получается 2 места, которые содержат информацию о формате и валидации в той или иной мере (ограничения и правила конфига и сам код программы)

Если проект большой и сложный, на составление конфига может быть хоть отдельный сервис и команда разработки быть выделенным =)

И, кстати, имхо проверку конфига должна выполнять программа, иначе получается 2 места, которые содержат информацию о формате и валидации в той или иной мере (ограничения и правила конфига и сам код программы)

Сама программа не проверяет валидность отдельных его полей

Она проверяет валидность конфига, по его хэшу

Т.к. система отдачи конфига в системе вообще не знает, что именно а нем хранится

И не должна, т.к. система постоянно развивается и конфиг расширяется

Вот всякие nginx, postgres, php, postfix, redis, и куча других утилит используют свои велосипеды, кто как справляется.

А сам модуль, отвечающий за конфиг, у нас уже давно (года 2) не меняется.

Вот всякие nginx, postgres, php, postfix, redis, и куча других утилит используют свои велосипеды, кто как справляется.

Далеко не все

Близко все )

Только пхп в ini файлах старается хранить

ERROR: S client not available

Да и то fpm имеет свой формат какой-то, поверх стандартных конфигов

Так, а как правильнее API спроектировать. Мне надо чтобы по запросу на урл были следующие методы: - добавить, удалить, проверить, получить список речь про получение списка email'ов {"add": "vasia@mail.ru"} ? И так для всех остальных?

или это криво?

Это ты описал REST по сути

Только методов болше надо...

Так добавь сколько тебе нужно

GET /entity/42/check

Мы от места ушли... Надоел

Так, а если просто как я написал сделать в виде json и POST запроса?

Можно для каждой сущности ввести отдельный URI, типа /device/, /user/

А можно все на входном пакете разрулить

Так, а если просто как я написал сделать в виде json и POST запроса?

POST запросы для получения данных не очень хорошо делать. Лучше GET

А так, можно с телом json, не принципиально

Так, а если просто как я написал сделать в виде json и POST запроса?

Так тоже можно, но в этом случаи входной пакет будет чуть больше инфы нести

POST запросы для получения данных не очень хорошо делать. Лучше GET

Субъективное мнение

А проверку сущности можно делать через какой-нибудь HEAD

А проверку сущности можно делать через какой-нибудь HEAD

Вот это уже не верно

Субъективное мнение

Почему ты все время все оспариваешь и выискиваешь какие-то крайние случаи? =)

Зачем смешивать протокол http и свой прикладной? Вы ещё предложите ошибки http кодами отдавайть

Почему ты все время все оспариваешь и выискиваешь какие-то крайние случаи? =)

Отчего же? Даже Фейсбук уходит от этого реста

Он уходит потому что есть потребность в этом. Которой у Дмитрия нету.

И Дмитрий не размером с фейсбук, и потребности и масштабы у него другие.

Субъективное мнение

По поводу этого обосную - POST запросы не кешируются на промежуточных серверах, а GET могут кешироваться, что экономит трафик. GET идемпотентный, POST нет.

По поводу этого обосную - POST запросы не кешируются на промежуточных серверах, а GET могут кешироваться, что экономит трафик. GET идемпотентный, POST нет.

А если игнорировать кеш?

https://stackoverflow.com/questions/39386001/can-i-use-post-method-to-get-data-and-get-method-to-post-data в RFC все описано, где тут субъективное мнение?

Т.к. кешировать ответы API сторонними серверами - имхо мувитон

Почему ты все время все оспариваешь и выискиваешь какие-то крайние случаи? =)

Потому, что имею большой опыт в построении публичных апи.

И сразу вижу те места, через которые лично проходил

Вот и все

Потому, что имею большой опыт в построении публичных апи.

И что этот опыт говорит что в RFC описан бред?

Сама программа не проверяет валидность отдельных его полей

Прямым образом программа содержит информацию о структуре конфига, а косвенным имеет возможность проверить валидность (пример: имя файла sqlite базы - наличие такого файла)

То же рест накрывается тазом, как только приложение выростает и переходишь на постоянные соединения, ну или добавляется второй агент, который работает через xmpp, или вебсокеты