Ну вот в примере выше, с разными паролями, мне же нужно сообщить клиенту, что данные невалидны и сказать, что именно не так. Чтобы клиент как-то на это отреагировал, например, отобразил ошибку пользователю. Ну то есть я не могу ответить просто 400 BAD REQUEST — нужно конкретизировать ошибку. А ошибку кидает форма и кроме текста ошибки у меня ничего нет.
Насчёт костылей согласен, но что-то же делать надо. Иначе у нас только англоязычные пользователи смогут пользоваться. Ну либо отказываться от django.forns и пилить что-то своё (чего очень не хотелось бы)
Ошибка «Login exists» — это не ошибка валидации формы. (меня интересуют именно формы)
Что происходит на клиенте — это его дело, будет ли он валидировать данные перед отправкой серверу, этим занимаются сторонние разработчики и их много.
Например, при регистрации клиент прислал два разных пароля, форма бросила ошибку, в которой есть исключительно строка. Вот её мне нужно превратить в цифровой код ошибки.
Тут ещё проблема с тем, что в словаре string_error->code_error у меня ключи на английском (точнее, там именно ключи, которые при желании можно и для английского языка локализовать), а если, например, клиент прислал заголовок Accept-Language с другим языком, то при сравнении текста ошибки с ключами в словаре, этот текст уже будет локализованным.
И вот тут я вижу два варианта:
1. Достать source string из lazy object'а и его сравнивать с ключами в словаре
2. Перед сравнением актировать локаль, у которой гарантированно нет перевода (и не будет) — то есть гарантировать, что будут сравниваться именно ключи. И потом вернуть в прежнее состояние (активировать ту локаль, которая была перед поиском кода ошибки соответствующего строке)
Мы не используем django models, соответственно, tastypie и т.д. нам не подходят. Собственно, от джанги у нас остались только урл-резолвинг и формы исключительно для валидации. Для GET, PUT, PATCH, DELETE у нас свои Resources, что-то вроде CBV, только заточенные под наши нужды.
API у нас юзается не аджаксом (у нас вобще как такового web UI нету), а сторонними клиентами, которым нужно отдавать код ошибки, если чтото пошло не так. Например, это может быть мобильный клиент и ему нужна не текстовая строка ошибки, а код.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Насчёт костылей согласен, но что-то же делать надо. Иначе у нас только англоязычные пользователи смогут пользоваться. Ну либо отказываться от django.forns и пилить что-то своё (чего очень не хотелось бы)