The document discusses Language Independent Validation Rules (LIVR) 2.0, detailing its purpose to validate various types of data across different platforms. It identifies 10 common issues with existing validators and proposes solutions, highlighting features like custom rules, hierarchical data support, and understandable error codes. Examples provided illustrate the validation of different data structures and the importance of customizing output types for consistent handling across programming languages.

1. Language Independent
Validation Rules (LIVR)
2.0
Viktor Turskyi
CTO at WebbyLab
OSDN-UA 2017

2. Example: validate registration data

3. LIVR Spec 2.0
Rules description - http://livr-spec.org/
Test suite -
https://github.com/koorchik/LIVR/tree/master/te
st_suite

4. Existing implementations
Perl (supported by WebbyLab)
JavaScript (supported by WebbyLab)
PHP (supported by WebbyLab)
Erlang (supported by community)
Python (supported by community)
Ruby (supported by community)

5. Why we need it?
● We develop under different platforms
● We validate different types of data
● There is no universal validator in the world

6. 10 issues of existing validators

7. Issue 1: Some validators pass
through fields which have no
validation rules described

8. Decision 1: Exclude all fields that do
not have validation rules described

9. Issue 2: Some validators use
procedural rules

10. Decision 2: Declarative validation.
Validation = Schema

11. Issue 3: Some validators describe
validation as a code

12. Decision 3: Validation = Data

13. Issue 4: Some validators fails on the
first error

14. Decision 4: Return together errors
for all fields

15. Issue 5: Some validators have non
standardized error messages.
Like “Field name is required”

16. Decision 5: Use error codes

17. Issue 6: Some validators have
numeric error codes

18. Decision 6: Understandable error
codes.
Like “NOT_POSITIVE_INTEGER”

19. Issue 7: Some validators do not
support hierarchical data structures

20. Decision 7: Support hierarchical
data structures of the box

21. Issue 8: Some validators are limited
by built-in rules

22. Decision 8: Support of custom rules
and aliases registration

23. Issue 9: Some validators have to
broad responsibility.
Like working with HTML etc

24. Decision 9: Single responsibility -
validation
This makes it multipurpose (user
input validation, configs validation,
contracts programming etc)

25. Issue 10: Some validators do not
support transformation of validation
data

26. Decision 10: Data pipelining in the
validator’s core

27. Example: validate registration data

28. Types of Rules
Just validation: ‘required’, ‘min_number’ etc
Meta rules: ‘nested_object’, ‘list_of’ etc
Modifiers: ‘trim’, ‘to_lc’, leave_only’ etc

29. Syntax details
# Short form
password: [ 'required', {min_length: 10} ]
# Full form
password: [ {required: [ ] }, { min_length: [10] } ]

30. Example: validate nested object
{
name: 'required',
phone: {max_length: 10},
address: { 'nested_object': {
city: 'required',
zip: ['required', 'positive_integer']
}}
}

31. Example: validate list
{
order_id: ['required', 'positive_integer'],
product_ids: { 'list_of': [
'required',
'positive_integer'
] }
}

32. Example: validate list of objects
{
order_id: ['required', 'positive_integer'],
products: [ 'not_empty_list', { 'list_of_objects': {
product_id: ['required','positive_integer'],
quantity: ['required', 'positive_integer']
}}]
}

33. Example: output modification
(pipelines)
{
email: [ 'trim', 'required', 'email', 'to_lc' ]
}

34. IMPLEMENTATION

35. Small universal core, all features are
in rules
For the core there is no difference between:
‘required’, ‘nested_object’, ‘trim’.

36. Custom rules

37. Aliased Rules (new feature)

38. Unified approach to types handling
How we deal with this:
● Perl (weak types with monomorphic
operators)
● JavaScript (weak types with polymorphic
operators)
● Python (strong types with polymorphic
operators)
● Erlang
● PHP
● Ruby

39. Output types matters
Input can be a string or a number but output
type should correspond to validation rule.
Input: {a: “23”, b: 23}
{a: ‘positive_integer’, b: ‘string’}
It means that you expect to get ‘a’ as positive
integer and ‘b’ as a string.

40. Output types matters
Input: {a: “23”, b: 23}
{a: ‘positive_integer’, b: ‘string’}
Output:
Perl a=”23” (looks like number), b=23 (can be used as
string)
JavaScript a=23 (type Number), b=”23” (type String)
Python=23 (type Int), b=”23” (type String)

41. Using LIVR for REST API
Request: POST /users

42. Response
which looks better than “Bad request” :)

43. Links
LIVR:
● LIVR Playground -
http://webbylab.github.io/livr-playground
● Specification https://github.com/koorchik/LIVR
● Universal test suite
https://github.com/koorchik/LIVR/tree/master/test_suite
● Article about LIVR - https://goo.gl/y1bTw1

44. Viktor Turskyi
viktor@webbylab.com
http://twitter.com/koorchik
https://github.com/koorchik
WebbyLab
http://webbylab.com