Comments 3
Если важно чтобы не было утечки знания, и важно чтобы именно 404 -- то таки лучше сделать так, чтобы исходный тест с 404 работал (прибив где надо гвозди или запатчив базу чтоб по всем поводам только 404 выкидывалось).
Если неважно -- то лучше тесте проверять что ошибка 4хх, а какая именно -- неважно.
Техника "поменяем тест чтоб проходил" порочна.
Отвечает автор статьи:
Да, согласны. Пожалуй, стоило прописать сразу же, что замена в тесте на 405 статус это, скорее, один из вариантов, и явно не самый лучший. К тому же, при таком статусе могут ещё и к безопасности возникнуть вопросы.
Но мы решили, что всё же не погружаться в эту тему и оставить тест таким, потому что статья, которая изначально планировалась «лёгким чтивом», по нашему мнению и без того уже выросла в объёме.
Проблема в том, что ReST это архитектура, а не протокол. Поэтому протокол можно сделать каким угодно, если он не противоречит её принципам и шести ограничениям. Из-за этого вероятность найти готовый инструмент под конкретные требования стремится к нулю - всегда приходится адаптировать.
Есть зоопарк из различных RFC, которые в разное время составляли под разные задачи. Попытки систематизировать и формализовать, скажем так, "web-ориентированный ReST" уже были - с четким алгоритмом в какой ситуации какой HTTP status code должен возвращаться. Например, такую работу проделали в Webmachine для Erlang, описав флоу в виде flow-диаграммы, машины состояний и тестов (мне также встречались порты для других языков). Но в массы это не пошло, а жаль - возможно мир стал бы гораздо проще.
Какого-то единообразия среди фреймворков и технологий нет. Каждый реализует протокол вмеру собственных предпочтений. Наименьший общим знаменателем становится OpenAPI (бывший Swagger). Но он определяет только формат, оставляя протокольную часть за рамками. Остальное решается на уровне соглашений, принятых в конкретной организации.
403, 404 или 405. Разбираемся со статусами во ViewSet’ах DRF