add validation API

[flosse]

[regenduft]

If we validate on submit only, we will not need an extra api, we could just submit and get appropriate error messages back.

Server needs to run the validation as part of this api call anyway.

[flosse]

So we have to define an error format. How should it look like? And what about the error messages? Who is responsible for i18n? If the client is responsible, we need error codes and if the server is responsible the client has to send the uses language.

[regenduft]

I like to have structured data to specify WHICH field has an error.

I think having only error codes, that specify which specific error did occur, will lead to either not enough different error codes, or new error codes beeing added all the time and thus clients will always be outdated and display "general failure" all the time.

So I would indeed prefer to have the i18n on the server side, because it is likely, that we add new validations and new failures in the future, and it should be one place (the api) that needs to be changed then, instead of changing the api and all clients (we plan to have 10 or more clients, somewhen) as soon as we add a new validation.

This means, the client needs to submit the language code he wants the error messages in, with the form data.

The response could then look like this:

errors: { name: 'May not have more than 20 characters', description: 'May not be empty', url: 'Needs to have the following format: http://domain.com/path' }

I know, that the temptation is big, to use somthing like this instead:

errors: { name: {code: 'maxlength', value: 20, message: 'Max not have more than 20 characters'} }

However, this will lead client developers into writing their own messages, and the server developers will think - 'oh, they use their own messages, I do not need to adde translations or write good messages'

Therefore, I would like it more to have no code at all, thus forcing the client developers to tell the server developers 'hey, your message is bad. please use this one...'.

But in the end, I also would be happy to have error codes AND messages, if and only if we select some very generic codes, to distinguish very different kinds of errors, that will likely NOT change in the future.

[regenduft]

mh, one thing.

in the case, that a translation for an error is not present, the client should be able to decide, if he displays a generic translated message or a specific english message.

so maybe we need something like

errors: { name: { en: 'May not have more than 20 characters', de: 'Maximal 20 Zeichen erlaubt' } }

where 'de' is the language-code that the user has submitted with the form for localized errors, and en is always present.

[regenduft]

another option would be, to use error codes and an extra api call to get the messages for error codes (which does only need to be retrieved once at beginning of a client session).

This way, the translations would still be part of the server, so only one thing to change when an error code gets added, but we reduce the amount of data going over the network.

[sebokopter]

As @regenduft said:

another option would be, to use error codes and an extra api call to get the messages for error codes (which does only need to be retrieved once at beginning of a client session).

This way, the translations would still be part of the server, so only one thing to change when an error code gets added, but we reduce the amount of data going over the network.

+1