API Tutorial Lesson 01 - Validating Type Values
Our first example displays the usage of the 'Valid' API (note that in all figures containing operation examples we have highlighted new APIs being used for the first time - in our sequence of operation examples - using a gray background). 'Valid' always takes two parameters: the first one represents the name of one of the types defined by our cloud-based time-limited transaction manager, while the second one provides the value that will be tested to be a correct value of that type. The 'Valid' API can be used both on types with a fixed set of values (like, for example, country codes and country names) as well as sets that can vary along time (as, for example, the set of all error codes defined on our transaction manager).
The 'Valid' API will return either 'true' or 'false', telling if the value passed in follows the rules for values of the specified type. However, it is important to note that the last block of code depicted the figure contains calls to the 'Valid' API which will return an error code (instead of 'true' or 'false'), in order to preserve security (note that the 'Valid' API does not require any kind of identification of who is calling it). The 'Valid' API will refuse giving out data about the structure of solutions (including methods, parameters, callbacks, properties, and so on) and about type values representing security tokens (like solution tokens or operation handles): these are Validated using other APIs, that can be called only by logged in users.
US Patent Requested