Powerful IDE for API-first design, documentation and development.

Start my Free Trial

One of the main objections to using canonical data models in our applications is that they are a one-size-fits-no-one solution. Developers would rather define the data structures they need from scratch, for each new application, rather than use types that are unfit for their purposes, that simply don’t give them what they need. If you add to this the difficulties of defining canonical data in the first place - assembling reluctant committees and battling endlessly for consensus - then you have to wonder why anyone would bother...

The problem is that APIs speaking different data dialects - saying the same kinds of things in an increasing variety of ways - are slower to learn and less interoperable. So organisations wishing to integrate themselves internally using RESTful APIs and/or expose external RESTful services, face growing costs for remedial integration technology. One way of taming these costs over time is to create APIs that use concepts drawn from a common library - a growing, canonical model-pedia of domain types. The question is how to do this practically. And the answer has to be satisfactory to both developers (who want to get the job done) and data people (who want to avoid rampant data chaos). 

At RepreZen, we have come up with a solution to this problem that actually makes things easier for API developers to do what they do. We call it 'realization modeling'. This allows developers to base APIs on canonical data definitions that they then adapt, within well-defined limits (the rules may be bent but *not* broken) to meet the specific needs of the API/service in question.