RepreZen API Studio Quick Start Guide » Sharing and Reusing Data Models

RESTful APIs present interfaces across which data can be exchanged, and in order to communicate with them we need to know both the media type(s) and the data types 'spoken' by the API in question. The common pattern is for each API to define its own data types, its own data language or way of saying things, in isolation. Clients of an API then have to learn the words of its language, and how they relate to each other, in order to be able to use it. Replicate this across a burgeoning number of APIs and you begin to see the scope of the challenge this presents both to API consumers, who have to learn the unique idiosyncrasies of each API's data dialect, and for API producers, who have to concoct the same kinds of data models over and over again. This is a fragmented and highly entropic state of affairs that makes it harder to get the most from the RESTful approach.

An important feature of RepreZen™ API Studio is that it enables and, in fact, encourages the sharing and reuse of data models across APIs. It thus helps oppose the tendency towards data model divergence (a babel of different data languages). We'll now look at how this reuse is achieved in the context of our TaxBlaster example.

Extracting the common data type(s)

We have now created a rapidModel that has two parts:

a)	A resourceAPI defining our RESTful API and

b)	A dataModel defining the data types used by our API.

There are parts of this dataModel that may be useful beyond the context of the TaxBlaster API, and we can share these by extracting them and making them accessible via some central location. We'll do this as follows:

1.	Create a new rapidModel in the current project called CommonDataModel and de-select Create GenTargets since we won't be generating anything from this model:

2.	The new rapidModel is just going to be a container for the dataModel, so we can delete the generated resourceAPI definition, and we can delete the generated structure because we will be moving structures over from the previous rapidModel. The resulting model will look like this:

3.	Next, we need to rename the generated dataModel to something more meaningful, say GeneralTypes:

4.	Now, by way of a basic demonstration, we'll pretend that the Person structure is reusable. Cut this from the TaxBlaster rapidModel and paste it into our CommonDataModel:

5.	Note: This causes errors in the TaxBlaster model since the Person data type can no longer be resolved:

We'll fix these errors by importing our new CommonDataModel into our TaxBlaster model. Put the following at the top of the TaxBlaster rapidModel (import statements must always be at the top of the model file). The errors should disappear.

import CommonDataModel.GeneralTypes from "CommonDataModel.rapid"

7.	We can check this import quickly by commenting out the import line (put the cursor in the left margin and press Ctrl+/) and noticing that the errors reappear:

Publishing our Common Data Model in a central location

If we want to share our data model with other API developers we need to publish it in some central, accessible location. The simplest way of doing this is to put our CommonDataModel.rapid file in a location that is accessible via HTTP.

1.	For speed, we'll do this using a public Github gist which you can find at the link below. Please feel free to use it. https://goo.gl/gGRP5P

2.	All we need to do now is add a line importing the data model from this URL. (Leave the local import commented out for now as we'll be needing that later.) The Person data type is then resolved from the remote dataModel and our errors disappear:

Anybody with access to this URL is now able to reuse our Person data type and any other types we choose to add to this rapidModel.

Adding namespaces

We are not just dependent on the rapidModel and dataModel names for our qualifiers. If needed we can go further by placing the rapidModel within a namespace.

1.	Add the following namespace declaration to the local copy of CommonDataModel.rapid: namespace com.modelsolv.quickstart Note: The use of namespaces allows us to scale all the way up to the enterprise, or even inter-enterprise, dataModel sharing and re-use.

2.	For speed, we'll revert back to importing the local copy of our common data model. Simply comment out the remote import and uncomment the local one like so:

The addition of a namespace in this example will cause errors in our rapidModel since the import statement now needs to include the namespace. We'll fix the import using Code Assist. Just delete CommonDataModel.GeneralTypes, press Ctrl+Space and select the fully qualified name of our local data model:

SharingAndReusingDataModels_12

The Person data type can now be found so all the remaining errors will disappear from the model.

Copyright © 2016 ModelSolv, Inc. All rights reserved. RepreZen and RAPID-ML are trademarks of ModelSolv, Inc. Swagger is a registered trademark of SmartBear Software, Inc. RepreZen API Studio is not associated with nor endorsed by SmartBear Software, Inc.