| 1.1, Аноним (1), 21:23, 21/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +13 +/– | |
Детсадовская поделка в сравнении с postgrest. Дисквалифицирована за одно только вот это:
GET /api/orders/?select=total:amount.sum(),order_date
Если это у них REST API, я лучше сразу SQL-запросы слать буду прямо в базу.
| | |
| |
| |
| 3.38, Аноним (1), 16:47, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Это две ортогональные вещи, нужные для разных задач. Операции над графами через классический REST API просто неудобны, получается ещё хуже, чем делать это на SQL.
А сабж — просто плохой дизайн REST API.
| | |
| |
| 4.49, test (??), 07:32, 23/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Может и плохой, хз почему так.
Но язык там нормльный для сервиса а не какая то дикая смесь хаскеля с питоном ...
| | |
|
|
| 2.28, laindono (ok), 10:50, 22/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Кстати, а какие вообще для SQL есть альтернативы? Именно в контексте реляционных баз данных.
| | |
| |
| 3.40, Аноним (1), 17:52, 22/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Для SQL в контексте реляционных данных альтернатив нет и я не уверен, что они нужны, по крайней мере на этом этапе развития. Проблема с реляционными ДБ не в выразительности языка запросов, а в ограничениях платформы (и ещё часто законов физики, которые постоянно мешают полёту мысли). Если что-то не укладывается хорошо в реляционную модель (например, графы), то нужно искать альтернативные модели. Язык запросов — дело десятое.
| | |
| |
| 4.56, Аноним (1), 18:28, 23/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Хорош для обхода графов и проверки утверждений, но с реляциями на нём — на мой вкус — сложнее работать чем с SQL.
| | |
|
| 3.66, Аноним (66), 23:25, 23/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Посмотри на принципы работы с данными в FoxPro - тоже реляционность, но куда интереснее и гибче.
| | |
|
| 2.32, penetrator (?), 15:28, 22/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
В REST нет SQL запросов даже в самой смелой интерпретации, альтернатива GraphQL но и там нет SQL
| | |
|
| 1.3, Аноним (3), 21:44, 21/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Немножко оффтопика: а как реализуется версионность записей в подобных задачах?
Ну типа была Иванова Наталья Иванована, стала Петрова Наталья Ивановна.
| | |
| |
| 2.5, Аноним (5), 21:55, 21/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Если база нагруженная просто пишешь новое поле. Ставь флаг что это поле актуальное или номер версии или как у вас принято.
| | |
| 2.41, Аноним (1), 18:02, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Если платформа не поддерживает напрямую, то можно через o2m отношение к таблице с версиями. Если такая необходимость есть для большинства полей, возможно подойдут триплеты (rdf), или quad store (для «стала Петровой 1970-01-01 в 11:02:19»). Оба варианта реализуются в обычной реляционной БД, так что не придётся даже менять платформу.
| | |
| 2.64, Аноним (66), 23:21, 23/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Каждый изобретает свою версионность, в зависимости от жёсткости требований - нет смысла спрашивать про одну конкретную реализацию.
| | |
|
| |
| |
| |
| 4.10, Аноним (-), 23:09, 21/04/2025 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> Единственный язык, который не вызывает религиозные споры
Еще как вызывает!
- где наследование как в плюсах?
- где нормальные дженерики??
- сборщик мусора тормозит!
- бинарник весит 100500Мб, а вот на сишечке пару кб!
И вообще "го сделали в гугле, чтобы заменить нормальных программистов на веб-mакаk и платить им меньше!")))
| | |
| 4.13, Аноним (1), 01:32, 22/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ты просто не застал. Достаточно было упомянуть микросервисную архитектуру на Го и начиналось. А потом все переключились на Раст, а на Го как писали микросервисы так и продолжают.
| | |
| |
| 5.31, Аноним (30), 14:20, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
На Go не стали переписывать библиотеки и UNIX-утилиты. Поэтому и забили.
| | |
| |
| 6.42, Аноним (1), 18:05, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
И это тоже делали на го. Каждый язык проходит через стадии взросления. Весь хейт раста (а до него хейт го, и я готов поставить деньги, что с Си в своё время было то же самое) — вторичен как песни Киркорова. Меняется только название языка и иногда люди. Слова все те же самые, а авторство утеряно в веках.
| | |
|
|
|
| 3.16, morphe (?), 05:38, 22/04/2025 [^] [^^] [^^^] [ответить]
| +2 +/– |
Golang не защищает от data race, а data race можно превратить в buffer overflow и много чего ещё, просто это не так просто как в Си
| | |
| |
| |
| 5.47, morphe (?), 22:55, 22/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> а как data-race превратить в buffer-overflow? Кусок кода или ссылку плиз
В golang для slice/interface используются fat pointers, и работа с ними не атомарна
Можно переписать одну половину (длину slice), но при этом оставив другую (указатель на данные) старой. Длина > размера аллокации (данных) - можно писать за пределы
https://go.dev/play/p/NKh_krw3Zni
| | |
| |
| 6.48, pavel_simple. (?), 06:11, 23/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> а как data-race превратить в buffer-overflow? Кусок кода или ссылку плиз
> В golang для slice/interface используются fat pointers, и работа с ними не
> атомарна
> Можно переписать одну половину (длину slice), но при этом оставив другую (указатель
> на данные) старой. Длина > размера аллокации (данных) - можно писать
> за пределы
> https://go.dev/play/p/NKh_krw3Zni
спасибо. Весьма занимательно. Правда так никто не пишет, да и если чел без башки начнёт работать в горутинах без примитивов синхронизации -- ССЗБ
| | |
| |
| 7.52, morphe (?), 11:30, 23/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> а как 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/многие другие таких проблем не имеют.
| | |
| 7.57, Аноним (1), 18:31, 23/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> работать в горутинах без примитивов синхронизации
CSP в помощь. Кто-то может поспорить, что канал тоже примитив синхронизации, но так-то можно и сову на глобус натянуть.
| | |
|
|
|
|
|
|
| |
| 2.18, Анониматор (?), 07:26, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
иньекцией было бы лучше, но там не так, самопальный типа CRUD (не знаю зачем и как это может упростить жизнь)
| | |
|
| 1.12, Аноним (12), 00:18, 22/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А шо у rest есть какой-то СТАНДАРТ??
Каждый веб-кодерок выдумывает свой собственный рест, по факту
| | |
| |
| 2.19, Анониматор (?), 07:30, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Есть рекомендации. Согласно им для получения данных надо использовать GET, и эти чуваки послушно так сделали. Про то что SQL-запрос может быть 100 килобайт они не слышали. На проде быстро обломаются.
| | |
| |
| 3.27, Cykooz (ok), 10:05, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
 Эту проблему уже решили - в прошлом году приняли в стандарт метод QUERY. По сути тот же GET, только в нём чётко прописано, что этот запрос может содержать тело.
Так то и GET может содержать тело, но поскольку в стандарте это не прописано явно, то некоторые веб-сервера просто не рассчитывают на это и могут работать не так как ожидается. Для этого и придумали QUERY.
| | |
| |
| 4.34, penetrator (?), 15:35, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
пока я так понял только черновик, ну и поддерживает его 0 веб-серверов
| | |
| |
| 5.37, Cykooz (ok), 16:45, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
> This Internet-Draft is submitted in full conformance with the provisions of
> BCP 78 and BCP 79.
Даас, действительно черновик ещё. Видимо я подзабыл детали прошлогодней новости.
Но ничего, если "REST-сервис" новый, модный, молодёжный, то может и сам сделать поддержку QUERY и заодно поддержку тела для GET запросов :-)
| | |
|
|
| 3.33, penetrator (?), 15:31, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
нет таких требований, можно для получение данных использовать любой HTTP verb, который уччитывает персонально твои ограничения
одно из требование - использование HTTP, но не конкретного VERB
то что так делают, а еще и возврат еррор кода в видео HTTP статуса - это от сложившихся стереотипов
| | |
| |
| 4.43, Аноним (1), 18:25, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> одно из требование - использование HTTP
Нет там никаких требований, REST — это архитектурный стиль, у него есть только свойства и ограничения. Традиционно в конечной реализации используется HTTP, как самый распространенный и доступный протокол, но вообще требования пользоваться именно HTTP нет. Любой протокол имеющий концепцию «глаголов» (команд) может быть использован как транспорт для REST. Шутки ради можно сделать реализацию даже через SMTP.
| | |
| |
| 5.51, penetrator (?), 10:58, 23/04/2025 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> одно из требование - использование HTTP
> Нет там никаких требований, REST — это архитектурный стиль, у него есть
> только свойства и ограничения. Традиционно в конечной реализации используется HTTP, как
> самый распространенный и доступный протокол, но вообще требования пользоваться именно
> HTTP нет. Любой протокол имеющий концепцию «глаголов» (команд) может быть использован
> как транспорт для REST. Шутки ради можно сделать реализацию даже через
> SMTP.
это не архитектурный стиль, а совокупность требований к реализации клиент-серверной архитектуры, их еще часто называют принципами построения REST сервисов
пока ты не выполняешь определенное условие (все условия) - твой сервис не считается RESTful
> но вообще требования пользоваться именно HTTP нет.
есть, можешь почитать другие мои посты в этой новости
> Шутки ради можно сделать реализацию даже через SMTP.
это будет что угодно но не REST, в SMTP нет hypertext, HATEOS невозможен
а еще там plain text т.е. стандартные форматы данных которые прописаны тоже не используются
| | |
| |
| 6.58, Аноним (1), 18:44, 23/04/2025 [^] [^^] [^^^] [ответить] | –1 +/– | Ты сейчас взял и описал архитектурный стиль, зачем-то подменив понятия и всунув ... большой текст свёрнут, показать | | |
|
|
|
|
| 2.24, Аноним (24), 09:35, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Три раза прочитал текст новости - так и не понял, откуда ты взял про стандарты.
| | |
| 2.25, Cykooz (ok), 09:48, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Стандарт есть у HTTP, который построен на принципах REST. Если осилить прочитать, хотя бы "популярные" пересказы этого стандарта во всяких вики-педиях и тому подобное, и следовать этому стандарту, то уже будет больше шансов получить на выходе API, который соответствует рекомендациям REST.
К сожалению многие "веб-кодерки" останавливаются на туманных объяснениях старших коллег за кружечкой пива. Поэтому и получается разношёрстая масса API со словом REST, которая даже HTTP не соблюдает.
| | |
| |
| 3.35, penetrator (?), 15:36, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
эпик фейл
это REST основан на HTTP а не наоборот, и там это всего лишь одно из требований, использовать его в качестве транспорта
| | |
| |
| 4.39, Cykooz (ok), 17:03, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
> эпик фейл
> это REST основан на HTTP а не наоборот, и там это всего
> лишь одно из требований, использовать его в качестве транспорта
В диссертации Филдинга, в разделе про REST, если и есть хоть какие-то упоминания HTTP, то их надо искать с лупой. Там точно нет ни чего про HTTP-методы и HTTP как транспорт. О каком транспорте можно говорить к контексте ПРИНЦИПОВ построения АРХИТЕКТУРЫ? Даже не построения самого "приложения" или "протокола", а только архитектуры клиент-серверного приложения.
Самое близкое, что можно притянуть из описания REST к HTTP, это использование URI для идентификации сущностей.
Тут наверное проблема курицы и яйца. Филдинг принимал прямое участие в разработке архитектуры HTTP. Придумал ли он принципы REST в процессе этого, или они сложились в его голове заранее - это уже не важно. Есть принципы, и есть пример готовой архитектуры, которая соответствует этим принципам.
И вот Вы как раз наглядный пример того, о чём я написал выше - многие сами не читали исходные документы, но думают, что знают о чём идёт речь. И такого очень много в интернете про REST.
| | |
| |
| 5.50, penetrator (?), 10:39, 23/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> Самое близкое, что можно притянуть из описания REST к HTTP, это использование
> URI для идентификации сущностей.
> Тут наверное проблема курицы и яйца. Филдинг принимал прямое участие в разработке
> архитектуры HTTP. Придумал ли он принципы REST в процессе этого, или
> они сложились в его голове заранее - это уже не важно.
> Есть принципы, и есть пример готовой архитектуры, которая соответствует этим принципам.
> И вот Вы как раз наглядный пример того, о чём я написал
> выше - многие сами не читали исходные документы, но думают, что
> знают о чём идёт речь. И такого очень много в интернете
> про REST.
https://oleb.net/2018/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% случаев люди, которые пишут такое не думают о себе самом,
ошибка выжившего
| | |
| |
| 6.53, Cykooz (ok), 11:32, 23/04/2025 [^] [^^] [^^^] [ответить] | +/– | Да, про это я и имел ввиду говоря, что скорее всего принципы REST сформировались... большой текст свёрнут, показать | | |
| |
| 7.59, Аноним (1), 18:53, 23/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Что делать, если от REST для решения задачи нужно всё, кроме HATEOAS? Является ли null HATEOAS частью сета всех возможных реализаций HATEOAS? В общем, оба вы загнались парни. Архитектурные стили информируют архитектора для принятия конкретных решений, а не диктуют как ему думать и как делать. Ещё раз повторюсь: это не догма, это набор возможнных реший для абстрактных типовых проблем, и решать как и какими именно воспользоваться для решения конкретных проблем в конкретном проекте — суть работы архитектора.
| | |
| 7.62, Аноним (66), 23:11, 23/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
> REST сформировались в процессе разработки HTTP
Что ты за чушь порешь?? HTTP был ПОЛНОСТЬЮ разработан ещё в 90-ые, там про новомодные RESTы даже не слышали! Это потом уже пришли пиджаки, стали дуть щёки и создавть какую-то overbloated теорию "как все должны запрашивать сервер". На ReSTе свет клином не сошёлся, можно вообще по FTP всё выдавать. Или по JSON-RPC. Вариантов море, главное - не прыгать к REST как с писаной торбой и считать её осью мироздания.
| | |
|
|
|
| 4.44, Аноним (1), 18:27, 22/04/2025 [^] [^^] [^^^] [ответить]
| +/– | |
Эпик фейл 2: возвращение эпик фейла.
REST не основан на HTTP или какой-либо другом протоколе.
| | |
|
|
|
| 1.17, Анониматор (?), 06:39, 22/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
у меня проще реализовано. никакие jwt не нужны, ведь авторизацию делает сам SQL и соединение хранится в пуле драйвера. А за безопасность должен отвечать DBA на уровне раздачи привилегий, поэтому борьба с инжекциями это всего лишь накладывание подорожника. Там пара сотен строк нужно всего чтоб такое наваять
| | |
| |
| 2.36, penetrator (?), 15:38, 22/04/2025 [^] [^^] [^^^] [ответить]
| +1 +/– | |
это если у тебя наколенная поделка, в которой нет логики и все умещается в DB-driven app
а если у тебя что-то уровня DDD, то хранилище для тебя абстрактно
| | |
| 2.63, Аноним (66), 23:15, 23/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
Это эпик фэйл, бро. Заниматься сложной настройкой прав только потому, что один клоун взвалил всё на DBMS - глупо. DBMS давно уже потеряла статус "апп-сервера" и стала тупо хранилищем. Умные люди наоборот - максимально дистанцируются от способа хранения данных (и тем более прав) и делают кастомные системы а-ля "группы-права групп", хранящиеся в тех же таблицах. Это позволяет максимально габко строить систему: захотел - перенёс всё в MS SQL. Захотел - вынес права в LDAP. Никто в здравом уме не надеется на то, что система прав DBMS будет идеально отражать права самой бизнес-системы.
Короче, переписывай свою чушь под более generic подход.
| | |
| |
| 3.67, Анониматор (?), 07:56, 24/04/2025 [^] [^^] [^^^] [ответить]
| +/– |
не, не буду. мой костыль заменяет вызовы ADODB вызовами REST в уже написанном софте, так что подразумевается что все права на БД уже настроены
| | |
|
|
| 1.60, Аноним (66), 23:00, 23/04/2025 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Это галиматья, а не проект. Очевидно же, что CRUD - лишь малая и самая бестолковая часть любого app.server'а! Её нет смысла "автоматизировать" ДАЖЕ если код у всех проектов совпадает на 80% - оставшиеся 20% и есть та самая "бизнес-логика", которую НИКАК не опишешь универсально, не прибегая к ЯОН. Закономерный вопрос: за каким якодзуном нужен этот EasyREST, если в нём нет никакого смысла и всё равно надо писать логику?? Причём логика неслабо так пересекается с самими выборками из базы, поэтому "тупых селектов" там точно будет по минимуму.
| | |
|
