The REST API in Rational Software Architect Design Management 4.0


Rational Software Architect’s Design Management capability (RSADM) is a Jazz based server application. Its primary API is HTTP REST. RSADM is also an OSLC compliant service provider that is based on linked data principals. The resources RSADM manages are all expressible in RDF.

RSADM is also an Open Services for Lifecycle Collaboration (OSLC) Architecture Management (AM) provider and implements all the required parts of the OSLC specifications. These are considered part of the RSADM ‘public’ API.

RSADM 4.0 is a significant release. It is the first RSADM release to fully support the entire lifecycle management of its resources, including versioning and configurations to support parallel development. Most of these concepts are not yet part of the OSLC specifications. Since the API for operations involving versioning and configurations are not yet defined by the OSLC, we consider these RSADM REST APIs as having ‘partner’ level visibility. That is; the API is available for use, and the RSADM architecture will try to preserve their integrity over time, however it can, and most likely will change as we align with future OSLC specifications that accomplish the same function.

RSADM has another category of APIs: ‘private’ that it uses internally. These APIs, should be considered likely to change over time, and are not intended to be used outside of the RSADM integrated clients and applications. In general when the API requires the special header “x-ibm-rmps-internal: true” then the API is internal, however not all internal APIs require this header. It is best to assume that unless the API is part of the OSLC specification, or has been explicitly documented as public, the API is private.

RSADM 4.0 is the first release that has started to document its REST API with dynamic generation of the documentation based on internal annotations in the source. The advantage of this is the documentation is coming directly from the code that implements the service, and much more likely to be in synch with the current version of the service. The documentation is exactly the right version for the given instance of the running service. Also, documentation is only available for services implemented on the runtime instance of the server. You will not find documentation of services that are not available.

In this initial release of the self documenting API, only a few of the services are completely documented. They can be viewed with the service URL of the form: https://host:port/dm/doc/services, where the host and port are those of the installed and setup server (Figure 1).

Figure 1 Design management service API

Figure 1 Design management service API


RSADM’s provides an HTTP based REST API. This API follows the IETF RFC 2616 specification, as well as the general spirit of the protocol. Being a Jazz based application RSADM’s authentication comes from the Jazz Foundation Services (JFS). JFS uses OAuth, and all service calls must contain valid OAuth tokens in the session cookies in order to be processed. Web clients get routed automatically to an authentication dialog, and then redirected back to the originally requested web resource. However programmatic clients must be prepared to authenticate, and ‘do the OAuth dance’ before working with RSADM and JFS services. The details of the OAuth protocol, and JFS’s implementation of them are beyond the scope of this article. See the developer works article, ”Add OAuth authentication support to HttpClient” for information about extending the Apache HTTP Client Java libraries for OAuth.

Working with RDF

Many of the resources used in the RSADM API are RDF. Most, but not all, of the services support several representations; RDF/XML, NTriple and Turtle. It is highly recommended that RDF resources be managed with a RDF library like Jena. Jena provides a Java API for reading, writing and processing RDF resources. While it is possible to parse and process RDF resources with other means, using Jena to process resources will guarantee their integrity as well as provide a simple API for access.

Root services document

RSADM being a Jazz based application, relies on a rootservices document. This RDF resource, always located at https://host:port/dm/rootservices lists all the main service end points for the RSADM application, and the Jazz application frameworks on which it is built. This resource does not require authorization. In fact it includes the OAuth authorization URLs necessary to complete the OAuth based authorization process. A client should start with this resource to find and derive the various service end points expected in the RSADM API.

Root services and finding service end points

This example simply GETs the root services document. This document contains the service end points for most of RSADM’s services, and serves as a starting point for all API scenarios.

The root services document is an RDF resource that all Jazz based applications provide, without authorization, to clients wishing to find specific service end points. This document includes OAuth URLs used in the OAuth based authentication process for non-web browser clients.

The root services document can be obtained in the following formats:

For example the client GETs the rootservices document passing in an Accept header of text/turtle as shown below.

  Request:  GET HTTP/1.1    Headers  Accept: text/turtle    Response:  HTTP/1.1 200 OK    Headers  Server: Apache-Coyote/1.1  ETag: "nQQLPGLvSXh8NEYQhFJslNFmDkI="  Date: Tue, 11 Sep 2012 15:25:28 GMT  Expires: Tue, 11 Sep 2012 15:30:28 GMT  Cache-Control: public  Content-Type: text/turtle;charset=UTF-8  Transfer-Encoding: chunked    @prefix jp:      <> .  @prefix fp:      <> .  @prefix ju:      <> .  @prefix jp06:    <> .  @prefix rh_dist:  <> .  @prefix oslc_am:  <> .  @prefix oslc:    <> .  @prefix oslc_rm:  <> .  @prefix rhlocator:  <> .  @prefix vvc:     <> .  @prefix jtp:     <> .  @prefix jdb:     <> .  @prefix dcterms:  <> .  @prefix rdf:     <> .  @prefix trs:     <> .  @prefix jfs:     <> .  @prefix jd:      <> .  @prefix rmps:    <> .  @prefix dc:      <> .    <>        dc:title "Design Management JTS-BaseLines Proxy" .  <>        dc:title "Design Management JTS-Indexing Proxy" .  <>        dc:title "Design Management of Tool's specific Leading Dimensions" .  <>        dc:title "Design Management for Existing Tools" .  <>        dc:title "Design Management JTS-Query Proxy" .  <>        dc:title "Rational Software Architect Import Service" .  <>        dc:title "Design Management" .  	    <>        ju:widgetCatalog <> ;        vvc:eventReceiver <> ;        rh_dist:baselines <> ;        rh_dist:distcenter <> ;        rh_dist:indexing <> ;        rh_dist:query <> ;        jdb:dashboards <> ;        jd:discovery <> ;        jd:friends <> ;        jd:infocenterRoot <> ;        jd:registration <> ;        jd:viewletServiceRoot                <> ;        jd:viewletWebUIRoot <> ;        fp:processProxy <> ;        jfs:adminWebUI <> ;        jfs:baselines <> ;        jfs:bulkOperations <> ;        jfs:changes <> ;        jfs:currentUser <> ;        jfs:history <> ;        jfs:indexing <> ;        jfs:jauthCheckAuthUrl                <> ;        jfs:jauthCheckTokenUrl                <> ;        jfs:jauthIssueTokenUrl                <> ;        jfs:jauthProxyUrl <> ;        jfs:jauthRevokeTokenUrl                <> ;        jfs:jauthSigninUrl <> ;        jfs:mailer <> ;        jfs:oauthAccessTokenUrl                <> ;        jfs:oauthApprovalModuleUrl                <> ;        jfs:oauthDomain "," ;        jfs:oauthExpireTokenUrl                <> ;        jfs:oauthRealmName "Jazz" ;        jfs:oauthRequestConsumerKeyUrl                <> ;        jfs:oauthRequestTokenUrl                <> ;        jfs:oauthUserAuthorizationUrl                <> ;        jfs:query <> ;        jfs:search <> ;        jfs:serverRenameStatus                <> ;        jfs:setupWizardDescriptor                <> ;        jfs:storage <> ;        jfs:users <> ;        jtp:associations <> ;        jtp:defaultPracticeLibraryUrl                <> ;        jtp:file <> ;        jtp:license <> ;        jtp:practices <> ;        jtp:processDescriptions                <> ;        jp06:processSecurity                <> ;        jp06:processTemplates                <> ;        jp06:projectAreas <> ;        jp:projectAreaInitService                <> ;        rhlocator:existingtools                <> ;        rhlocator:ld <> ;        rhlocator:locate <> ;        rmps:auth <> ;        rmps:clmSampleProject                <> ;        rmps:comments <> ;        rmps:compare <> ;        rmps:compareWithPrevious                <> ;        rmps:design <> ;        rmps:diagrams <> ;        rmps:dm-baselines <> ;        rmps:dm-changesets <> ;        rmps:dm-history <> ;        rmps:dm-search <> ;        rmps:dm-users <> ;        rmps:dminstall <> ;        rmps:domainRegistry <> ;        rmps:dsf <> ;        rmps:dsv <> ;        rmps:dtkConfigure <> ;        rmps:dtkEditorDef <> ;        rmps:explorer <> ;        rmps:fileUpload <> ;        rmps:folders <> ;        rmps:graphLayout <> ;        rmps:groups <> ;        rmps:imageInfo <> ;        rmps:importer <> ;        rmps:info <> ;        rmps:linkServiceProviders                <> ;        rmps:links <> ;        rmps:linktypes <> ;        rmps:logical <> ;        rmps:metamodelconverter                <> ;        rmps:migration <> ;        rmps:modelquery <> ;        rmps:models <> ;        rmps:modelvalidation                <> ;        rmps:oslcquery <> ;        rmps:owlInput <> ;        rmps:projects <> ;        rmps:properties <> ;        rmps:queries <> ;        rmps:queryvvc <> ;        rmps:rdfdirectory <> ;        rmps:rendering <> ;        rmps:resourceState <> ;        rmps:reviews <> ;        rmps:status <> ;        rmps:streams <> ;        rmps:subscriptions <> ;        rmps:support <> ;        rmps:trackedResourceSetProvider                [ a       trs:TrackedResourceSetProvider ;                  trs:trackedResourceSet                          <>                ] ;        rmps:transforms <> ;        rmps:validation <> ;        rmps:web <> ;        oslc_am:amServiceProviders                <> ;        oslc:publisher <> ;        oslc_rm:rmServiceProviders                <> ;        dc:title "Design Management"@en .    <>        dc:title "Design Management Query and Search Services".  

With the root services document you can find the service endpoint for most of DM’s services, as well as services exposed by Jazz Foundation Services (JFS). It is highly recommended that you use an RDF parser to process this document. To find the service end point that you are interested in you must know the property URI of the service. For example to find the DM projects service end point we use the projects service property: to find the statement with this property ( rmps:projects ). In this example the projects service URL is ( ).


The remainder of this article explains the API with examples.

GETing resource representations

The following examples demonstrate simple resource access. The OSLC representation is a subset of all the internal properties of any DM managed resource. They include some basic properties like title and description, along with links to other OSLC backed resources. Some DM resources are diagram resources. For these it is possible to get an image/* representation of them. The following examples demonstrate simple resource access.

Finding resources with OSLC Simple Query

The client uses the OSLC defined Simple Query service to search for resource matches in a given RSADM project. Each RSADM project has its own query base URL, which scope the query to just the resources in the associated project. The following examples demonstrate first how to find the query end point for a given project, then executing some queries for resources. DM supports both RDF/XML and Atom response formats.

Managing OSLC Links

An OSLC link is, for all practical purposes just a property on a resource that points to another OSLC resource. The property themselves are not part of any of ontologies that define the resources, but rather are a DM managed extension to the resource, and can be put on any resource. RSADM allows links, of any type, from any resource it manages. Following the OSLC guidelines, links are represented as simple RDF properties, and may have properties itself. Creating and removing links from RSADM resource is done by GETing the OSLC representation of a resource, adding the link properties to it, and PUTing it back to the server.

When editing resource in RSADM 4.0 it is important to be aware of the configuration that the changes are being made in. Since the current version of the OSLC specifications do not address configurations, the configuration in which the links are created and removed must be set in the projects properties.

The following examples demonstrate how to use the OSLC representation to create and manage links from DM resources to other OSLC backed resources.

Creating and editing resources

RSADM 4.0 introduces powerful new configuration management capabilities. All changes to resources must be viewed and made within a configuration context. The configuration URI is required as a query parameter for all changeset operations. Configuration information is obtained from the configuration service. This set of scenarios demonstrates how to create and edit custom resources. The ontology used here come from the DM supplied ‘Examples’ domain. This domain includes an ontology for resources that describe Authors and Books. The scenarios below show how to use changesets to manage the creation and editing of these simple resource types.

Editing RSA UML resources

RSA DM provides a full UML2 ontology, and with the RSA desktop client UML model elements can be created and managed in DM. RSA UML resources managed by RSADM contain a number of properties that are not visible in the OSLC representation. It is still possible to edit these properties, however the API to do so should be considered ‘partner’ level, and not public. This means that while the API is available for use, it may change or be deprecated in the next release.

The following scenario demonstrates how the REST API can be used to make simple changes to the resource’s internal properties.

Summary and Next Steps

The RSADM REST API follows standard HTTP and REST principals. Its official public API is the OSLC AM and OSLC RM specification, however this is limited to managing OSLC links on resources. Full resource management is done in the context of configurations, and requires the use of non-public APIs in RSADM 4.0. This article describes the API through a series of example scenarios.

The Design Management project on offers a 60 day trial so you can download and try it out. Additionally the library section on contains articles, videos and other resources you may find helpful in learning more.

Was this information helpful? Yes No 5 people rated this as helpful.