4

An interesting question I've stumbled upon:

Let's assume a java application creates a data model, converts this data to a json object with two fields and uploads it to a server:

{
    "FirstName": "Foo",
    "LastName": "Bar"
}

Now a different technology, say js, php, etc on the server needs to process the data.

Both sides are well tested against a set of unit tests but naturally integration across different languages and technologies is hard to be tested in depth.

Is there a known principle or technique that can validate the data on both ends? I mean lets say there is a contract that says that LastName must not, by any chance be <2 chars in size. This is a business rule which is a hard constraint on the data.

Now the java implementation has a bug or simply overlooked the requirement for LastName. Both sides complete unit tests but they fail hard during integration.

Is there some technique that allows to specify such rules across languages? I am not talking about runtime rejection of malformed data but rather ensure consistency on both sides of an application.

Improve this question
7
  • 1
    It sounds like you're looking for an XML Schema, but for JSON. Is that correct? Commented Mar 23, 2018 at 21:54
  • You're not alone - been wondering if it is possible too. Still not sure if there is any ready-made solution. These are the ideas I have come up with so far - the validation rules must: (1) be coded as expression trees, compilable at run-time into every target language; (2) be immediately testable in the language of declaration; (3) produce exactly same result on every platform; (4) be essential part of the object schema so that applications willing to talk same entities also know the rules; (5) respect i18n and l10n. Commented Mar 23, 2018 at 21:55
  • @DanPichelman, JSON was an example, there are JSON Schema too. The requirements may be much more complex that a schema can handle, for instance only a subset of values allowed in LastName when FirstName is "World", etc Commented Mar 23, 2018 at 22:31
  • @yegodm I agree, although I would prefer code generation to avoid the need to spin up a rule engine and incur overhead Commented Mar 24, 2018 at 7:30
  • 3
    You need a common language to describe the validation rules on both ends. JSON Schema is surely an option, another one is to use an programming eco system which is suitable for all the clients or servers involved, so you can simply put the logic into one reuseable library. For example, JS/Node may allow you to write modules you can use in Browser code as well as in Server code. Commented Sep 24, 2018 at 15:11

3 Answers 3

Reset to default
1

Integration Testing

You succinctly describe the root issue here, namely lack of integration testing.

Both sides complete unit tests but they fail hard during integration.

The team building the Java application forgot to include validation and unit tests for when LastName is less than two characters.

The team building the PHP application, on the other hand, remembered to include the validation and unit tests.

Luckily, the QA team knew about the LastName requirement and added the name Jin-u O in their integration testing suite. When they called an API operation in the Java application using that name, expecting a 400-level validation error, they instead got a 200 and the test failed.

Is integration testing easy? Absolutely not. But it's definitely worth it if you've got the time and resources to test your applications against an objective set of criteria.

Improve this answer
1

The phrase I've come across for this is single source of truth:

In information systems design and theory, single source of truth (SSOT) is the practice of structuring information models and associated data schema such that every data element is stored exactly once. Any possible linkages to this data element (possibly in other areas of the relational schema or even in distant federated databases) are by reference only. Because all other locations of the data just refer back to the primary "source of truth" location, updates to the data element in the primary location propagate to the entire system without the possibility of a duplicate value somewhere being forgotten.

Software can be generated as noted above:

In software design, the same schema, business logic and other components are often repeated in multiple different contexts, while each version refers to itself as "Source Code". To address this problem, the concepts of SSoT can also be applied to software development principals using processes like recursive transcompiling to iteratively turn a single source of truth into many different kinds of source code, which will match each other structurally because they are all derived from the same SSoT.

Specifically, some cross language specifications include:

Projects such as Apache Thrift normalize this:

Apache Thrift allows you to define data types and service interfaces in a simple definition file. Taking that file as input, the compiler generates code to be used to easily build RPC clients and servers that communicate seamlessly across programming languages. Instead of writing a load of boilerplate code to serialize and transport your objects and invoke remote methods, you can get right down to business.

References

Improve this answer
2
  • Paul, thank you for improving the term I was describing in less precise terms. While not really an answer I see why posting this abstract would be hard when doing it as a comment. Commented Sep 25, 2018 at 10:48
  • @Samuel An interface file such as that used by OpenAPI or an interface definition language such as the Web IDL may be closer to the cross-language contract you are looking for. There was a question about cross-language naming conventions which may help. Commented Sep 25, 2018 at 13:48
0

JSON Schema has validator implementations in more than 17 languages. Which probably makes it the most cross-language object validation methodology. The implementations do vary a bit in completeness though.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.