тогда варианта с тайпингом явно не хватит. Из очевидного 2 стула, пидантик с одним полем или isinstance

Тут такая штука, что idки вообще-то не следует как-либо валидировать дальше чем что это строка. Потому что за id отвечает обычно какой-то другой сервис (db) и оно и так знает всё про типы, форматы и ограничения. Дублировать тоже самое на уровне приложения (клиент или сервер) - лишнее.

Ну как. Строчка тоже может стать "'; drop table...."

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

Ну это уже немного другой вопрос, строчку драйвер проэкранировать должен как следует

Если программист делает в соотвествии с рекомендациями

Ну и пусть, ты же эту строку не через строковые операции вставляешь в запрос (;

База сама тебе скажет всё что думает про твои данные если что-то не совпадает с её схемой. Зачем поддерживать две схемы данных, когда должна быть единая точка ответственности за них?

Потому что это разные зоны ответственности

как вариант, чтобы вернуть пользователю 400 код и осмысленное сообщение об ошибке

Это почему же они разные?

Кастомизация ошибок - ок, но обычно это не сильно нужно. Можно отзеркалить оригинальное сообщение под 400 кодом.

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

Пользователю лучше никакие ошибки не показывать, а всё же принять его запрос и как-то дообработать чуть позже (;

а то я часто вижу API, которые говорят 400, а что им не нравится непонятно

Может в контексте было непонятно, но данные приходят из внешней системы, они могут прийти в любом виде — это отдельный контур твоего приложения, которому всё равно что дальше — кака базая и есть ли она вообще. Ответственность этой зоны принять данные, сверить что контракт не нарушен и пропустить их дальше или нет.

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

Всё так, но я не уверен что такие промежуточные контракты чем-то полезны. Ты ведь врядли будешь валидировать idшки на их соответствие спекам objectid / uuid4 или же что они укладываются в постгревый bigint - кстати, как это всё в пидантике описать?

это любой uuid, не uuid4

У пидантика есть свой кастомный тип UUID4