Стоит ли использовать длинные пути в endpoint или можно сделать проще

Что проверяют

Есть ли у вас правило, по которому вы решаете, что кладётся в путь, что в параметры запроса, а что в тело. Проверяют не вкус, а понимание, что опубликованный адрес это контракт, который потом дорого менять.

Как отвечать

Сформулируйте принцип: путь адресует ресурс, параметры запроса описывают выборку. Вложенность оправдана, когда дочерний объект не существует без родителя или когда его идентификатор уникален только внутри родителя. Если идентификатор заказа уникален сам по себе, короткий путь к заказу читается лучше длинного и не требует проверять принадлежность на каждом уровне.

Рабочие ориентиры:

• не больше двух уровней вложенности;
• фильтры, сортировка и пагинация в параметрах запроса;
• действие выражается методом HTTP, а не глаголом в пути;
• владелец данных берётся из токена, а не из адреса.

Для Python-стека добавьте практику: во FastAPI вложенные адреса разносятся по роутерам с общим префиксом и общими зависимостями, так что длинный путь не означает громоздкий код. И скажите, что такие вещи фиксируются в соглашении по API, иначе каждый разработчик придумывает свой стиль, а клиенты живут с обоими.

Где спотыкаются

Спорят про длину и забывают про доступ. Адрес с чужим идентификатором пользователя без проверки прав отдаёт чужие данные, и это первое, что находит любой аудит безопасности.

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

Утверждают, что короткие пути работают быстрее. Разница в несколько байтов в строке запроса не измерима, цена длинного пути в читаемости, количестве проверок и поддержке, а не в производительности.