Коды ошибок в django.forms?

Question

[krinart]

При ошибках валидации django.forms возвращают текстовые сообщения с описанием ошибки. Для построения REST API это не очень удобно, так как требуется возвращать ещё и код ошибки. Приходится хранить словарь вот такого вида:

message_codes = {<br>
    'password': {<br>
        'default': errors.InvalidPassword,<br>
        'This field is required': errors.PasswordMissing,<br>
    },<br>
    'newPassword': {<br>
        'default': errors.InvalidPassword,<br>
        'This field is required': errors.PasswordMissing,<br>
    },<br>
}<br>

Может кто-нибудь знает, сталкивался, как можно это улучшить, возможно даже сторонними средствами? Наткнулся на вот такую штуку pypi.python.org/pypi/validate, но пока ещё не успел глубоко копнуть.

Answer 1

[barker]

Ну, тут больше пожалуй и правда никак, т.к. из clean приходят только экзепшены с текстом, и собираются они внутри тоже с текстом в словарь по именам полей. Эта штука по ссылке, как я понял, делает то же самое (сопоставляет). В своих clean (формы, полей итд) так-то можно возвращать и с кодом и как угодно, просто не очень понятно на каком уровне у вас REST API. Если выше форм, то никак не сделаете, т.к. собирается внутри форм всё равно в словарь. Если ниже, ну так тут либо свои валидации, либо + в дополнение перекрывать стандартные.

Answer 2

[realduke]

Вообще обычно стараются выделить логику обработки данных в отдельные модули. А для построения REST API используют специальные инструменты наподобии tastypieapi.org или django-rest-framework.org.

Вам же нужно обрабатывать GET, PUT, UPDATE, DELETE и т.д. Как вы это делаете при помощи форм?

Comments

[realduke]

UPDATE -> PATCH, прошу прощения.

[krinart]

Мы не используем django models, соответственно, tastypie и т.д. нам не подходят. Собственно, от джанги у нас остались только урл-резолвинг и формы исключительно для валидации. Для GET, PUT, PATCH, DELETE у нас свои Resources, что-то вроде CBV, только заточенные под наши нужды.

API у нас юзается не аджаксом (у нас вобще как такового web UI нету), а сторонними клиентами, которым нужно отдавать код ошибки, если чтото пошло не так. Например, это может быть мобильный клиент и ему нужна не текстовая строка ошибки, а код.

[realduke]

Ну тогда не вижу проблем. Валидация выполняется на стороне клиента. На сервере достаточно знать прошла валидация или нет. Ну и возвращаете коды ошибок для специфичных случаев данного ресурса. К примеру, имеем регистрацию, пользователь вводит логин, почту, пароль, может еще что-то. Вы проверяете на клиенте, что поля валидные. А когда к примеру занят логин, то возвращаете HTTP статус 400 Bad Request, ну и JSON что-нибудь типа {'error': 1, 'message': 'Login exists.'}. Зачем вам гонять по каналу ненужные сообщени о валидации, они должны быть четко описаны в спецификации к программному интерфейсу. Вам и формы-то не нужны по идее, нужны только валидаторы, если все равно нет HTML морды. Или у вас какие специфичные требования, которых я не понимаю?

[realduke]

Еще в последнее время тенденция такова, что числовые коды ошибок уже не являются особо хорошей практикой. Экономия всего несколько байтов, а код invalid_request или processing_error гораздо читабельнее и легче в отладке, не нужно смотреть на 100500 описаний ошибок. Главное чтобы было четко описанное подмножество ошибок.

[krinart]

Ошибка «Login exists» — это не ошибка валидации формы. (меня интересуют именно формы)

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

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

Тут ещё проблема с тем, что в словаре string_error->code_error у меня ключи на английском (точнее, там именно ключи, которые при желании можно и для английского языка локализовать), а если, например, клиент прислал заголовок Accept-Language с другим языком, то при сравнении текста ошибки с ключами в словаре, этот текст уже будет локализованным.

И вот тут я вижу два варианта:
1. Достать source string из lazy object'а и его сравнивать с ключами в словаре
2. Перед сравнением актировать локаль, у которой гарантированно нет перевода (и не будет) — то есть гарантировать, что будут сравниваться именно ключи. И потом вернуть в прежнее состояние (активировать ту локаль, которая была перед поиском кода ошибки соответствующего строке)

[realduke]

Простите, всё же не понимаю, зачем конкретные данные ошибок из формы? При осуществлении операции вам недостаточно ответа на вопрос валидны ли данные? Ну и если валидны, то пытаемся выполнить операцию, если не валидные возвращаем клиенту статус о невалидности данных.

Ваше решение с локализованными кодами как-то смахивает на костыль.

[krinart]

Ну вот в примере выше, с разными паролями, мне же нужно сообщить клиенту, что данные невалидны и сказать, что именно не так. Чтобы клиент как-то на это отреагировал, например, отобразил ошибку пользователю. Ну то есть я не могу ответить просто 400 BAD REQUEST — нужно конкретизировать ошибку. А ошибку кидает форма и кроме текста ошибки у меня ничего нет.

Насчёт костылей согласен, но что-то же делать надо. Иначе у нас только англоязычные пользователи смогут пользоваться. Ну либо отказываться от django.forns и пилить что-то своё (чего очень не хотелось бы)

[realduke]

> Ну вот в примере выше, с разными паролями, мне же нужно сообщить клиенту, что данные невалидны и сказать, что именно не так. Чтобы клиент как-то на это отреагировал, например, отобразил ошибку пользователю. Ну то есть я не могу ответить просто 400 BAD REQUEST — нужно конкретизировать ошибку. А ошибку кидает форма и кроме текста ошибки у меня ничего нет.

Так вы же сами говорите, что клиент сам валидирует. Чтобы ограничить себя от ошибок вам достаточно знать, что все введённые поля соотвествуют заявленному формату. Т.е. вы отделяете логику валидации, которую может выполнить клиент, от логики валидации на серверной стороне. Пишете в спеке для тех, кто клиент реализует, что пароль такой-то длины, может содержать от стольки до стольки символов и т.д. Пусть они сами занимаются обработкой этих данных. А на серверной стороне вам достаточно проверить, что переданные данные соотвествуют заявленному формату, А вот если валидация на серверной стороне не выполняется, ну к примеру может быть так, что вам нужно, чтобы как минимум последние три пароля были уникальными, то вы уже возвращаете ошибку и не просто статус 400, а JSON с заранее регламентированным кодом.

Django forms как раз и создавались для удобства валидации в том числе данных из моделек, ну и с возвратом текстовых сообщений для пользователя, с учётом локализации и прочего. Так что в вашем случае они особо и не нужны.

Если django models не используете, то где хранятся данные? Может я что смогу подсказать.

Answer 3

[realduke]

И еще не совсем понятно: если у вас REST API, то зачем вам обрабатывать ошибки форм, а если вы просто хотите использовать AJAX и сериализованные в JSON ошибки форм, то чем текстовые сообщения не устраивают?