API Guide

HTTP Message Bodies

All HTTP Requests and Responses support both XML and JSON content types. The examples used throughout this document show

HTTP body content in XML form. The represented data models accepted and returned by the API calls can be quite complex. The

structure of these data models is detailed in Appendix B in a language independent representation. While it is possible to craft say an

XML request body from this reference documentation, a much more convenient method is to GET an existing object from ASM in

the desired representation ( XML or JSON ) and save it to a le for use as a skeleton for future requests involving that model type.

Since a fresh system will not have any existing Deployments. A Deployment model is shown below for illustration. It is actually only a

skeleton because it is lacking the essential ServiceTemplate content that would make it useful. For more information see the Usage

Example called Deploy a Service.

<?xml version="1.0" encoding="UTF-8"?>

<deploymentName>Ottomatic</deploymentName>

<deploymentDescription>test REST deployment</deploymentDescription>

<allUsersAllowed>false</allUsersAllowed>

<canCancel>false</canCancel>

<canDelete>false</canDelete>

<canDeleteResources>false</canDeleteResources>

<canEdit>false</canEdit>

<canMigrate>false</canMigrate>

<canRetry>false</canRetry>

<canScaleupApplication>false</canScaleupApplication>

<canScaleupCluster>false</canScaleupCluster>

<canScaleupServer>false</canScaleupServer>

<canScaleupStorage>false</canScaleupStorage>

<canScaleupVM>false</canScaleupVM>

<updateServerFirmware>false</updateServerFirmware>

<individualTeardown>false</individualTeardown>

<teardown>false</teardown>

<retry>false</retry>

</serviceTemplate>

</Deployment>

Validations

Message bodies are subject to a wide range of validations. Capturing every validation rule is currently beyond the scope of this

document but a few general rules are worth noting.

• In general validation failures generate exceptions and structured messages to isolate the violation. See the section on Exception

Handling for more details. Most validation exceptions return a 400 HTTP response, but some API methods generate specic

HTTP response codes to indicate particular exceptions. These are listed in the API reference in the Appendix.

• Uniqueness validations. Many models require unique names. Notable models include ServiceTempate, Deployment, Network,

User. This violation returns a 409 HTTP response in these cases.

• Relationship constraints. In the case of deletion, an exception will occur when trying to delete an entity which is being used by

another entity.

• In a ServiceTemplate containing a Server component, if a hostname is supplied in addition to a hostname_template (hostname

generator ), this will not generate a validation exception and the behavior is to use the hostname_template over the supplied

hostname.