Кстати говоря, господа, а как вы фильтры в openapi описываете?

Кто-нибудь скинет пример с полноценной фильтрацией?

Вопрос открыт. Я вот немного попробовал, и выходит как-то громоздко

Зависит от параметров и сложности фильтров. В твоём примере лучше сделать не ne:0, а отталкиваться всё же от каких-то более абстрактных понятий. Например, сделать ?onlyActive=true (активные - то есть не удалённые). Или наоборот onlyDeleted=true. Если нужна прямо реально сложная фильтрация, то в некоторых случаях стоит присмотреться к GraphQL. Я не сторонник этой технологии, но это хотя бы стандартизировано, а всякие ne:0 - это собственный велосипед

Тоже так думаю, что это переизобретение graphql) Но graphql - это отдельная технология, там есть свою нюансы и проблемы Вообще, если делать с операторами - это придётся упарываться в enum'ы. А вот если без них, то в query можно cкармливать модель определённую в definitions/schemas, и тогда выглядит не всё так плохо :)

Если фильтров много и нужны очень гибкие с кучей возможностей, то в REST это получится всегда велосипед) Я бы в таком случае предпочёл GraphQL даже несмотря на его недостатки. Лучше бороться с его недостатками, чем с велосипедами

то есть для всех бекофисов брать графкл, а для других нужд пилить обычный рест или грпц? так ни в какие сроки не успеешь. а в графкл: там еще н+1 проблемы реши рекурсии порешай.

а велосипедов и нет. сделал либу и внедрил ее везде. другие люди видят косяки, чинят, пр делают

Это всё очень зависит от задачи. Вполне может оказаться, что эндпоинты с гибкой фильтрацией нужны для каких-то отчётов, скажем, а больше нигде. И ничего не мешает именно эти эндпоинты сделать в виде GraphQL, а не натягивать сову на глобус, пытаясь всё API проекта в GraphQL пилить

Вообще, на go инструмент уже написан, которому можно скармливать подобные операторы, и его можно переиспользовать Но конечно хотелось бы, чтобы это отражалось и в спецификации тоже

долго. дорого. длень

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

это не велосипед. кажется ты подменяешь понятия. до создания графкл что делать?))

Почему ж не велосипед? Я ещё ни разу не видел сложной фильтрации в параметрах url, которая бы не выглядела как какой-то костыль. Причём то, как эти параметры будут выглядеть, надо выдумывать. И каждый проявляет фантазию и выдумывает это по-своему... Я бы предпочёл готовое решение вместо этого)

давай вернемся на 10 лет назад и выберем готовое решение

Ну, слушай, так можно и на 20 лет назад вернуться и обнаружить, что Go не существует)

передергиваешь ;-) по твоей логике, все кроме графкл — велосипед? и до его создания - все велосипеды.

Почему ж всё?) Я его так-то не люблю и вообще использую очень мало. Я пишу насчёт велосипедов конкретно в контексте тех случаев, когда разрабы придумывают сложную логику фильтрации в параметрах URL с какими-то разделителями, вложенностью и парсингом этого дела. Да, на мой взгляд, это не самое удачное решение. 10 лет назад я б может так и делал, т.к. выбирать особо не из чего. Сейчас для меня конкретно для этой задачи GraphQL выглядит более удачным выбором. P.s. правда вроде 10 лет назад был Open Data Protocol - и можно было б его выбрать, если так. Как бы там ни было - это тоже стандарт.

Но на начальных этапах намного быстрее и дешевле внедрить готовое, хоть и не настолько гибкое решение

Зависит от того, насколько сложная фильтрация

Конечно. Я об этом с самого начала сказал

фильтрация не бывает просто почти никогда если она правда нужна.

не релевантен пример с ОДП, я такого даже не знаю ;)