https://m.opennet.dev/openforum/vsluhforumID3/136668.html Состоялся выпуск EasyREST 0.8, лёгковесного расширяемого REST&#8209;сервиса для выполнения CRUD и агрегированных запросов к реляционным базам данных. Проект написан на языке Go и использует систему плагинов для подключения к различным СУБД (SQLite, MySQL, PostgreSQL, Redis). Код распространяется под лицензией Apache 2.0. Для запуска достаточно собрать или загрузить исполняемый файл и указать плагины в YAML&#8209;файле конфигурации или через переменные окружения...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=63114<br> https://m.opennet.dev/openforum/vsluhforumID3/136668.html#68 Thu, 24 Apr 2025 22:20:25 GMT Просто оставлю это здесь https://github.com/onegreyonewhite/easyrest/wiki/EasyREST-%E2%80%94-Performance%E2%80%90Testing-Manual<br> https://m.opennet.dev/openforum/vsluhforumID3/136668.html#67 Thu, 24 Apr 2025 04:56:50 GMT не, не буду. мой костыль заменяет вызовы ADODB вызовами REST в уже написанном софте, так что подразумевается что все права на БД уже настроены<br> https://m.opennet.dev/openforum/vsluhforumID3/136668.html#66 Wed, 23 Apr 2025 20:25:08 GMT Посмотри на принципы работы с данными в FoxPro - тоже реляционность, но куда интереснее и гибче.<br> https://m.opennet.dev/openforum/vsluhforumID3/136668.html#64 Wed, 23 Apr 2025 20:21:29 GMT Каждый изобретает свою версионность, в зависимости от жёсткости требований - нет смысла спрашивать про одну конкретную реализацию.<br> https://m.opennet.dev/openforum/vsluhforumID3/136668.html#63 Wed, 23 Apr 2025 20:15:44 GMT Это эпик фэйл, бро. Заниматься сложной настройкой прав только потому, что один клоун взвалил всё на DBMS - глупо. DBMS давно уже потеряла статус "апп-сервера" и стала тупо хранилищем. Умные люди наоборот - максимально дистанцируются от способа хранения данных (и тем более прав) и делают кастомные системы а-ля "группы-права групп", хранящиеся в тех же таблицах. Это позволяет максимально габко строить систему: захотел - перенёс всё в MS SQL. Захотел - вынес права в LDAP. Никто в здравом уме не надеется на то, что система прав DBMS будет идеально отражать права самой бизнес-системы.<br>Короче, переписывай свою чушь под более generic подход.<br> https://m.opennet.dev/openforum/vsluhforumID3/136668.html#62 Wed, 23 Apr 2025 20:11:11 GMT &gt; REST сформировались в процессе разработки HTTP<br><br>Что ты за чушь порешь?? HTTP был ПОЛНОСТЬЮ разработан ещё в 90-ые, там про новомодные RESTы даже не слышали! Это потом уже пришли пиджаки, стали дуть щёки и создавть какую-то overbloated теорию "как все должны запрашивать сервер". На ReSTе свет клином не сошёлся, можно вообще по FTP всё выдавать. Или по JSON-RPC. Вариантов море, главное - не прыгать к REST как с писаной торбой и считать её осью мироздания.<br> https://m.opennet.dev/openforum/vsluhforumID3/136668.html#60 Wed, 23 Apr 2025 20:00:31 GMT Это галиматья, а не проект. Очевидно же, что CRUD - лишь малая и самая бестолковая часть любого app.server'а! Её нет смысла "автоматизировать" ДАЖЕ если код у всех проектов совпадает на 80% - оставшиеся 20% и есть та самая "бизнес-логика", которую НИКАК не опишешь универсально, не прибегая к ЯОН. Закономерный вопрос: за каким якодзуном нужен этот EasyREST, если в нём нет никакого смысла и всё равно надо писать логику?? Причём логика неслабо так пересекается с самими выборками из базы, поэтому "тупых селектов" там точно будет по минимуму.<br> https://m.opennet.dev/openforum/vsluhforumID3/136668.html#59 Wed, 23 Apr 2025 15:53:11 GMT Что делать, если от REST для решения задачи нужно всё, кроме HATEOAS? Является ли null HATEOAS частью сета всех возможных реализаций HATEOAS? В общем, оба вы загнались парни. Архитектурные стили информируют архитектора для принятия конкретных решений, а не диктуют как ему думать и как делать. Ещё раз повторюсь: это не догма, это набор возможнных реший для абстрактных типовых проблем, и решать как и какими именно воспользоваться для решения конкретных проблем в конкретном проекте &#8212; суть работы архитектора.<br> https://m.opennet.dev/openforum/vsluhforumID3/136668.html#58 Wed, 23 Apr 2025 15:44:47 GMT &gt; это не архитектурный стиль, а совокупность требований к реализации клиент-серверной архитектуры, их еще часто называют принципами построения REST сервисов<br><br>Ты сейчас взял и описал архитектурный стиль, зачем-то подменив понятия и всунув туда &#171;требований&#187; вместо &#171;свойств&#187; и &#171;ограничений&#187;. Ну ок, пусть будут требования. Also, википедия прям первой строкой даёт: &#171;REST (Representational State Transfer) is a software architectural style&#187;. Видимо, они в сговоре со мной против тебя. И Рой Томас Филдинг тоже, описав REST в своей диссертации &#171;Architectural Styles and the Design of Network-based Software Architectures&#187;.<br><br>&gt; пока ты не выполняешь определенное условие (все условия) - твой сервис не считается RESTful<br><br>Кем не считается? RESTful Authority? Архитектурный стиль не догма, его можно и нужно менять под задачу, а не наоборот.<br><br>&gt; это будет что угодно но не REST, в SMTP нет hypertext, HATEOS невозможен<br><br>В HTTP hypertext есть только в названии, но передавать п