Состоялся выпуск EasyREST 0.8, лёгковесного расширяемого REST‑сервиса для выполнения CRUD и агрегированных запросов к реляционным базам данных. Проект написан на языке Go и использует систему плагинов для подключения к различным СУБД (SQLite, MySQL, PostgreSQL, Redis). Код распространяется под лицензией Apache 2.0. Для запуска достаточно собрать или загрузить исполняемый файл и указать плагины в YAML‑файле конфигурации или через переменные окружения...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63114
Детсадовская поделка в сравнении с postgrest. Дисквалифицирована за одно только вот это:GET /api/orders/?select=total:amount.sum(),order_date
Если это у них REST API, я лучше сразу SQL-запросы слать буду прямо в базу.
А то ж эксперт Аноним дисквалифицировал, значит слушаем!
Это чем-то напоминает поделия вроде GraphQL
Это две ортогональные вещи, нужные для разных задач. Операции над графами через классический REST API просто неудобны, получается ещё хуже, чем делать это на SQL.А сабж — просто плохой дизайн REST API.
Может и плохой, хз почему так.
Но язык там нормльный для сервиса а не какая то дикая смесь хаскеля с питоном ...
Кому-то шашечки, кому-то ехать. На всех не угодишь ¯\_(ツ)_/¯
Кстати, а какие вообще для SQL есть альтернативы? Именно в контексте реляционных баз данных.
Для SQL в контексте реляционных данных альтернатив нет и я не уверен, что они нужны, по крайней мере на этом этапе развития. Проблема с реляционными ДБ не в выразительности языка запросов, а в ограничениях платформы (и ещё часто законов физики, которые постоянно мешают полёту мысли). Если что-то не укладывается хорошо в реляционную модель (например, графы), то нужно искать альтернативные модели. Язык запросов — дело десятое.
Их там нет!(С);-)
Datalog
Хорош для обхода графов и проверки утверждений, но с реляциями на нём — на мой вкус — сложнее работать чем с SQL.
Посмотри на принципы работы с данными в FoxPro - тоже реляционность, но куда интереснее и гибче.
В REST нет SQL запросов даже в самой смелой интерпретации, альтернатива GraphQL но и там нет SQL
Немножко оффтопика: а как реализуется версионность записей в подобных задачах?Ну типа была Иванова Наталья Иванована, стала Петрова Наталья Ивановна.
Если база нагруженная просто пишешь новое поле. Ставь флаг что это поле актуальное или номер версии или как у вас принято.
Если платформа не поддерживает напрямую, то можно через o2m отношение к таблице с версиями. Если такая необходимость есть для большинства полей, возможно подойдут триплеты (rdf), или quad store (для «стала Петровой 1970-01-01 в 11:02:19»). Оба варианта реализуются в обычной реляционной БД, так что не придётся даже менять платформу.
Каждый изобретает свою версионность, в зависимости от жёсткости требований - нет смысла спрашивать про одну конкретную реализацию.
Ну что? Теперь в этот раз без выходов границ буфера?)))
Проект на Go написан. На безопасном языке.
Единственный язык, который не вызывает религиозные споры
> Единственный язык, который не вызывает религиозные спорыЕще как вызывает!
- где наследование как в плюсах?
- где нормальные дженерики??
- сборщик мусора тормозит!
- бинарник весит 100500Мб, а вот на сишечке пару кб!И вообще "го сделали в гугле, чтобы заменить нормальных программистов на веб-mакаk и платить им меньше!")))
ещё эти err != nil везде
Его в ядро не пихают, вот этим, в первую очередь, и хорош.
Ты просто не застал. Достаточно было упомянуть микросервисную архитектуру на Го и начиналось. А потом все переключились на Раст, а на Го как писали микросервисы так и продолжают.
Надо просто изобрести новый язык и начать про него много писать, чтоб от растоманов отстали всякие уверенные в себе анонимы, которые знают как надо правильно.
На Go не стали переписывать библиотеки и UNIX-утилиты. Поэтому и забили.
И это тоже делали на го. Каждый язык проходит через стадии взросления. Весь хейт раста (а до него хейт го, и я готов поставить деньги, что с Си в своё время было то же самое) — вторичен как песни Киркорова. Меняется только название языка и иногда люди. Слова все те же самые, а авторство утеряно в веках.
Golang не защищает от data race, а data race можно превратить в buffer overflow и много чего ещё, просто это не так просто как в Си
а как data-race превратить в buffer-overflow? Кусок кода или ссылку плиз
> а как data-race превратить в buffer-overflow? Кусок кода или ссылку плизВ golang для slice/interface используются fat pointers, и работа с ними не атомарна
Можно переписать одну половину (длину slice), но при этом оставив другую (указатель на данные) старой. Длина > размера аллокации (данных) - можно писать за пределы
>> а как data-race превратить в buffer-overflow? Кусок кода или ссылку плиз
> В golang для slice/interface используются fat pointers, и работа с ними не
> атомарна
> Можно переписать одну половину (длину slice), но при этом оставив другую (указатель
> на данные) старой. Длина > размера аллокации (данных) - можно писать
> за пределы
> https://go.dev/play/p/NKh_krw3Zniспасибо. Весьма занимательно. Правда так никто не пишет, да и если чел без башки начнёт работать в горутинах без примитивов синхронизации -- ССЗБ
>>> а как data-race превратить в buffer-overflow? Кусок кода или ссылку плиз
>> В golang для slice/interface используются fat pointers, и работа с ними не
>> атомарна
>> Можно переписать одну половину (длину slice), но при этом оставив другую (указатель
>> на данные) старой. Длина > размера аллокации (данных) - можно писать
>> за пределы
>> https://go.dev/play/p/NKh_krw3Zni
> Правда так никто не пишетТут код написан так, чтобы компилятор произвёл в бинарнике всё верно
Если нужно чужой код проверять - то можно уязвимые гаджеты в выхлопе дизассемблера искать> начнёт работать в горутинах без примитивов синхронизации -- ССЗБ
Ну вот и снова имеем что "правильные разработчики таких ошибок не совершают!". Тем временем в том же kubernetes гонки находят каждый месяц.
Да и проблема тут может быть на стыке нескольких модулей, где один third-party, а ты с ним работаешь не так как создатель ожидал, и тем самым провоцируешь гонку в нём.
А был бы golang memory-safe - он бы не позволял такие уязвимости вообще иметь без unsafe.
Rust/Java/Python/C#/OCaml/многие другие таких проблем не имеют.
>[оверквотинг удален]
> дизассемблера искать
>> начнёт работать в горутинах без примитивов синхронизации -- ССЗБ
> Ну вот и снова имеем что "правильные разработчики таких ошибок не совершают!".
> Тем временем в том же kubernetes гонки находят каждый месяц.
> Да и проблема тут может быть на стыке нескольких модулей, где один
> third-party, а ты с ним работаешь не так как создатель ожидал,
> и тем самым провоцируешь гонку в нём.
> А был бы golang memory-safe - он бы не позволял такие уязвимости
> вообще иметь без unsafe.
> Rust/Java/Python/C#/OCaml/многие другие таких проблем не имеют.Спасибо. Принято. С моей скромной тз -- ошибка должна быть крайне редкая, правда я давно не пейсал что-то связанное ebpf и ваще с сишным кодом
> работать в горутинах без примитивов синхронизацииCSP в помощь. Кто-то может поспорить, что канал тоже примитив синхронизации, но так-то можно и сову на глобус натянуть.
Тупо sql инжектят, вот и все плагины.
иньекцией было бы лучше, но там не так, самопальный типа CRUD (не знаю зачем и как это может упростить жизнь)
А шо у rest есть какой-то СТАНДАРТ??
Каждый веб-кодерок выдумывает свой собственный рест, по факту
Есть рекомендации. Согласно им для получения данных надо использовать GET, и эти чуваки послушно так сделали. Про то что SQL-запрос может быть 100 килобайт они не слышали. На проде быстро обломаются.
Ещё б Аноним почитал бы сперва, что там не sql передаётся...
Эту проблему уже решили - в прошлом году приняли в стандарт метод QUERY. По сути тот же GET, только в нём чётко прописано, что этот запрос может содержать тело.Так то и GET может содержать тело, но поскольку в стандарте это не прописано явно, то некоторые веб-сервера просто не рассчитывают на это и могут работать не так как ожидается. Для этого и придумали QUERY.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
пока я так понял только черновик, ну и поддерживает его 0 веб-серверов
> This Internet-Draft is submitted in full conformance with the provisions of
> BCP 78 and BCP 79.Даас, действительно черновик ещё. Видимо я подзабыл детали прошлогодней новости.
Но ничего, если "REST-сервис" новый, модный, молодёжный, то может и сам сделать поддержку QUERY и заодно поддержку тела для GET запросов :-)
нет таких требований, можно для получение данных использовать любой HTTP verb, который уччитывает персонально твои ограниченияодно из требование - использование HTTP, но не конкретного VERB
то что так делают, а еще и возврат еррор кода в видео HTTP статуса - это от сложившихся стереотипов
> одно из требование - использование HTTPНет там никаких требований, REST — это архитектурный стиль, у него есть только свойства и ограничения. Традиционно в конечной реализации используется HTTP, как самый распространенный и доступный протокол, но вообще требования пользоваться именно HTTP нет. Любой протокол имеющий концепцию «глаголов» (команд) может быть использован как транспорт для REST. Шутки ради можно сделать реализацию даже через SMTP.
>> одно из требование - использование HTTP
> Нет там никаких требований, REST — это архитектурный стиль, у него есть
> только свойства и ограничения. Традиционно в конечной реализации используется HTTP, как
> самый распространенный и доступный протокол, но вообще требования пользоваться именно
> HTTP нет. Любой протокол имеющий концепцию «глаголов» (команд) может быть использован
> как транспорт для REST. Шутки ради можно сделать реализацию даже через
> SMTP.это не архитектурный стиль, а совокупность требований к реализации клиент-серверной архитектуры, их еще часто называют принципами построения REST сервисов
пока ты не выполняешь определенное условие (все условия) - твой сервис не считается RESTful
> но вообще требования пользоваться именно HTTP нет.
есть, можешь почитать другие мои посты в этой новости
> Шутки ради можно сделать реализацию даже через SMTP.
это будет что угодно но не REST, в SMTP нет hypertext, HATEOS невозможен
а еще там plain text т.е. стандартные форматы данных которые прописаны тоже не используются
> это не архитектурный стиль, а совокупность требований к реализации клиент-серверной архитектуры, их еще часто называют принципами построения REST сервисовТы сейчас взял и описал архитектурный стиль, зачем-то подменив понятия и всунув туда «требований» вместо «свойств» и «ограничений». Ну ок, пусть будут требования. Also, википедия прям первой строкой даёт: «REST (Representational State Transfer) is a software architectural style». Видимо, они в сговоре со мной против тебя. И Рой Томас Филдинг тоже, описав REST в своей диссертации «Architectural Styles and the Design of Network-based Software Architectures».
> пока ты не выполняешь определенное условие (все условия) - твой сервис не считается RESTful
Кем не считается? RESTful Authority? Архитектурный стиль не догма, его можно и нужно менять под задачу, а не наоборот.
> это будет что угодно но не REST, в SMTP нет hypertext, HATEOS невозможен
В HTTP hypertext есть только в названии, но передавать по нему можно всё, что угодно. HATEOAS (а не Hate OS которую ты только что изобрёл вполне в духе фрейдизма) вообще никак не диктует формат данных. Большинство реализаций используют в качестве формата JSON, который отнюдь не гипертекст.
> а еще там plain text т.е. стандартные форматы данных которые прописаны тоже не используются
Что за стандартные форматы? Ну-ка, приведи ссылочку на стандарт.
Три раза прочитал текст новости - так и не понял, откуда ты взял про стандарты.
Стандарт есть у HTTP, который построен на принципах REST. Если осилить прочитать, хотя бы "популярные" пересказы этого стандарта во всяких вики-педиях и тому подобное, и следовать этому стандарту, то уже будет больше шансов получить на выходе API, который соответствует рекомендациям REST.К сожалению многие "веб-кодерки" останавливаются на туманных объяснениях старших коллег за кружечкой пива. Поэтому и получается разношёрстая масса API со словом REST, которая даже HTTP не соблюдает.
эпик фейлэто REST основан на HTTP а не наоборот, и там это всего лишь одно из требований, использовать его в качестве транспорта
> эпик фейл
> это REST основан на HTTP а не наоборот, и там это всего
> лишь одно из требований, использовать его в качестве транспортаВ диссертации Филдинга, в разделе про REST, если и есть хоть какие-то упоминания HTTP, то их надо искать с лупой. Там точно нет ни чего про HTTP-методы и HTTP как транспорт. О каком транспорте можно говорить к контексте ПРИНЦИПОВ построения АРХИТЕКТУРЫ? Даже не построения самого "приложения" или "протокола", а только архитектуры клиент-серверного приложения.
Самое близкое, что можно притянуть из описания REST к HTTP, это использование URI для идентификации сущностей.
Тут наверное проблема курицы и яйца. Филдинг принимал прямое участие в разработке архитектуры HTTP. Придумал ли он принципы REST в процессе этого, или они сложились в его голове заранее - это уже не важно. Есть принципы, и есть пример готовой архитектуры, которая соответствует этим принципам.
И вот Вы как раз наглядный пример того, о чём я написал выше - многие сами не читали исходные документы, но думают, что знают о чём идёт речь. И такого очень много в интернете про REST.
>[оверквотинг удален]
> Самое близкое, что можно притянуть из описания REST к HTTP, это использование
> URI для идентификации сущностей.
> Тут наверное проблема курицы и яйца. Филдинг принимал прямое участие в разработке
> архитектуры HTTP. Придумал ли он принципы REST в процессе этого, или
> они сложились в его голове заранее - это уже не важно.
> Есть принципы, и есть пример готовой архитектуры, которая соответствует этим принципам.
> И вот Вы как раз наглядный пример того, о чём я написал
> выше - многие сами не читали исходные документы, но думают, что
> знают о чём идёт речь. И такого очень много в интернете
> про REST.вот почитаешь, цитата упомянутого тобой автора:
REST was originally referred to as the “HTTP object model,” but that name would often lead to misinterpretation of it as the implementation model of an HTTP server.
и все его документы пестрят про HTTP и hypertext, uri и бла бла
но дело даже не в этом, понимание по Филдингу и как совокупность практик устоявшихся в среде немного отличаются друг от друга, так в его работах подчёркивается, что многие API, называющие себя RESTful, нарушают принципы, заложенные в HTTP (например, игнорируют HATEOAS).
я видел только один сервис с HATEOAS c которым я работал, но все равно считаю все остальныые тоже REST, кстати вариант HATEOAS был самой ушллепочной реализацией и проблемной с точки зрения использования клиентом
> многие сами не читали исходные документы, но думают, что знают о чём идёт речь
в 100% случаев люди, которые пишут такое не думают о себе самом,
ошибка выжившего
> REST was originally referred to as the “HTTP object model,” but that
> name would often lead to misinterpretation of it as the implementation
> model of an HTTP server.
> и все его документы пестрят про HTTP и hypertext, uri и бла
> блаДа, про это я и имел ввиду говоря, что скорее всего принципы REST сформировались в процессе разработки HTTP. Но по итогу, в диссертации, эти принципы, с названием REST, описаны без какой либо привязки к HTTP.
> но дело даже не в этом, понимание по Филдингу и как совокупность
> практик устоявшихся в среде немного отличаются друг от друга, так в
> его работах подчёркивается, что многие API, называющие себя RESTful, нарушают принципы,
> заложенные в HTTP (например, игнорируют HATEOAS).
> я видел только один сервис с HATEOAS c которым я работал, но
> все равно считаю все остальныые тоже REST, кстати вариант HATEOAS был
> самой ушллепочной реализацией и проблемной с точки зрения использования клиентомЯ читал в разных местах обсуждение HATEOAS и сделал вывод, что те, кто его ругал, просто не разобрались в нём. Обычно у них какая-то странная каша в голове на этот счёт, приправленная собственными выдумками. Люди почему-то считают, что для его реализации нужен какой-то супер клиент с ИИ внутри, который будет волшебным образом сам ходить по ссылкам из ответа сервера, угадывая, что надо на эти ссылки отправлять.
Может эти люди просто никогда не делали API, который потом развивали и поддерживали многие годы? И потому они не очень понимают какие в этом случае могут возникать проблемы и задачи.
Конечно, можно и без HATEOAS сделать архитектуру, но тогда, как сказал сам Филдинг, незачем лепить в название слово REST. А то это будет как если телегу назвать автомобилем, только потому что у неё есть колёса (маркетинг аля али-экспресс). Такая недоREST архитектура будет вполне себе работать. Только в некоторых кейсах она будет требовать значительных усилий при внесении изменений. Как и везде - это вопрос приоритетов и соотношения выгоды к затратам. Если нужно, что-то что должно десятилетиями работать и поддерживать старые версии клиентов/серверов - делай сразу по уму.
Что делать, если от REST для решения задачи нужно всё, кроме HATEOAS? Является ли null HATEOAS частью сета всех возможных реализаций HATEOAS? В общем, оба вы загнались парни. Архитектурные стили информируют архитектора для принятия конкретных решений, а не диктуют как ему думать и как делать. Ещё раз повторюсь: это не догма, это набор возможнных реший для абстрактных типовых проблем, и решать как и какими именно воспользоваться для решения конкретных проблем в конкретном проекте — суть работы архитектора.
> REST сформировались в процессе разработки HTTPЧто ты за чушь порешь?? HTTP был ПОЛНОСТЬЮ разработан ещё в 90-ые, там про новомодные RESTы даже не слышали! Это потом уже пришли пиджаки, стали дуть щёки и создавть какую-то overbloated теорию "как все должны запрашивать сервер". На ReSTе свет клином не сошёлся, можно вообще по FTP всё выдавать. Или по JSON-RPC. Вариантов море, главное - не прыгать к REST как с писаной торбой и считать её осью мироздания.
Эпик фейл 2: возвращение эпик фейла.REST не основан на HTTP или какой-либо другом протоколе.
у меня проще реализовано. никакие jwt не нужны, ведь авторизацию делает сам SQL и соединение хранится в пуле драйвера. А за безопасность должен отвечать DBA на уровне раздачи привилегий, поэтому борьба с инжекциями это всего лишь накладывание подорожника. Там пара сотен строк нужно всего чтоб такое наваять
это если у тебя наколенная поделка, в которой нет логики и все умещается в DB-driven appа если у тебя что-то уровня DDD, то хранилище для тебя абстрактно
Это эпик фэйл, бро. Заниматься сложной настройкой прав только потому, что один клоун взвалил всё на DBMS - глупо. DBMS давно уже потеряла статус "апп-сервера" и стала тупо хранилищем. Умные люди наоборот - максимально дистанцируются от способа хранения данных (и тем более прав) и делают кастомные системы а-ля "группы-права групп", хранящиеся в тех же таблицах. Это позволяет максимально габко строить систему: захотел - перенёс всё в MS SQL. Захотел - вынес права в LDAP. Никто в здравом уме не надеется на то, что система прав DBMS будет идеально отражать права самой бизнес-системы.
Короче, переписывай свою чушь под более generic подход.
не, не буду. мой костыль заменяет вызовы ADODB вызовами REST в уже написанном софте, так что подразумевается что все права на БД уже настроены
Тут только CRUD или полноценный CORUND?
То есть, это не OData? Нафиг он такой красивый нужен?
Это галиматья, а не проект. Очевидно же, что CRUD - лишь малая и самая бестолковая часть любого app.server'а! Её нет смысла "автоматизировать" ДАЖЕ если код у всех проектов совпадает на 80% - оставшиеся 20% и есть та самая "бизнес-логика", которую НИКАК не опишешь универсально, не прибегая к ЯОН. Закономерный вопрос: за каким якодзуном нужен этот EasyREST, если в нём нет никакого смысла и всё равно надо писать логику?? Причём логика неслабо так пересекается с самими выборками из базы, поэтому "тупых селектов" там точно будет по минимуму.
Просто оставлю это здесь https://github.com/onegreyonewhite/easyrest/wiki/EasyREST-&#...