---
schema_version: "1"
id: d1fcbdca419a059b36df9a30a0995f2bb8e8248e5499e43e6a163af5654c7da0
title: Understanding the Elements in an API Schema
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/datagraph/schemas.md
canonical_url: https://docs.mulesoft.com/datagraph/schemas
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 3f8e8b46cc4e0a2965317364a02c2ab8dfdf2e514e6ca1ce35e6c5dc4f2dfd50
description: MuleSoft Documentation Site
latest: true
---
---
product: DataGraph
---
# Understanding the Elements in an API Schema
> For the full documentation index, see: https://docs.mulesoft.com/llms.txt
Anypoint DataGraph organizes all data that you choose to make available to your clients in a unified
schema. The unified schema is a single, always-current collection of all of the schemas of all of
the APIs that you add to it.
When you add a new API to your unified schema, Anypoint DataGraph generates an API schema from the
API’s RAML or OAS specification. Because each API schema is created when its API is added, your
unified schema is always up to date. And because all API schemas are stored individually in your
organization, you can edit them individually without affecting the integrity of other schemas.
The API schema that Anypoint DataGraph generates contains a collection of the GET resources and
entities, and the relationships between them, that you’ve defined in your API specification.
Whenever you add a new API schema to the unified schema, you can configure the types and fields that
the unified schema will include.
Before learning about the different configurations that you can apply to a type, read the following
topic to understand the different types that can be present in your API schema depending on your API
specification.
## Object Types and Fields
The most common type in a schema, object types represent entities in your API specification that are
returned as part of a GET response. Object types are descriptively named and contain fields that
indicate the object properties.
For example, in a RAML specification, each type element of the specification becomes either an
object, enum, or union type. And the properties of each type element are the fields of those object
types in the API schema:
RAML API Specification
API Schema
#%RAML 1.0
title: Order API
types: Order: type: object properties: orderId: date: status:
Product: type: object properties: productId: name: brand:
/orders/{id}: get: displayName: Get Order by ID
Both `Order` and `Product` are different object types, each with different fields, that can be
represented as follows:
```none
type Order {
orderId: ID!
date: String!
status: String!
}
```
```none
type Product {
productId: ID!
name:String!
brand: String!
}
```
### Field Data Types
Each field represents a type’s dataset that is returned in a query response. By default, there are
five scalar types:
- `Int`:
A signed 32‐bit integer.
- `Float`:
A signed double-precision floating-point value.
- `String`:
A UTF‐8 character sequence.
- `Boolean`:
`true` or `false`.
- `ID`:
The ID scalar type represents a unique identifier, often used to refetch an object or as the key
for a query method. The ID type is serialized in the same way as a String; however, defining it as
an ID signifies that it is not intended to be human‐readable.
### Non-nullable Fields
Fields with values represented with a `!` sign are non-nullables, meaning that the field cannot
respond with a null value. For example, in the `Product` type, ID cannot be null:
```none
type Product {
productId: ID!
name:String
brand: String
}
```
And in the `Order` type, none of the values can be null:
```none
type Order {
orderId: ID!
name: String!
price: String!
brand: Int!
}
```
## Query Types and Methods
A query type is the entry point to your API schema when you make a request. A query type contains
the query methods that represent the GET endpoint you’ve defined in your API specification.
For example, in a RAML specification that defines a GET endpoint at `/orders/{id}`, the query method
in the schema is `ordersById(id)`:
RAML API Specification
API Schema
#%RAML 1.0
title: Order API
/orders/{id}: get: displayName: Get Order by
ID
ordersById(id):
Order
## Level-1 and Nested Types
The types in your schema belong to categories that depend on the relation between your type and the
query methods:
- Level-1 type
These types have a query method associated with them and therefore can be accessed directly.
For example, in the previous API specification, `Order` is a Level-1 object type because there is
a GET for the `order/{id}` endpoint associated with it.
You can access this object type using the query method directly:
```none
ordersById (orderId: “123”) {
orderId
date
}
```
- Nested types
These types have no query methods associated with them and therefore you can access them only
through the query methods of Level-1 types.
For example, in the previous API specification, `Product` is an object type with no query methods
associated with it. To query the fields of the `Product` type, you must query the method
associated with its Level-1 type `Order`:
```none
ordersById(id: "123") {
orderId
product {
name
price
}
}
```
Following this structure, query methods can be considered a level 0 type.
## Enum Types
Enum types are types that can only return a specific set of values. Enum types can be declared in
the API specification to ensure that a field always returns a finite set of values.
For example, assume a RAML specification that defines an `OrderStatus` type that must return one of
the object types `Processing`, `Completed`, or `Canceled`:
RAML API Specification
API Schema
#%RAML 1.0
title: Order API
types: OrderStatus: type: string description: Current status of the order enum: [Processing,
Completed, Canceled]
## Union Types
Union types describe instances of data using other object types. Union types consists of one or more
specific object types.
For example, a RAML specification can define the type `Product` using other types, such as
`Notebook` and `Phone`:
RAML API Specification
API Schema
#%RAML 1.0
title: Order API
types:
Product: type: Phone | Notebook
Notebook: type: object properties: manufacturer: type: string numberOfUSBPorts: type: number kind:
string
Phone: type: object properties: manufacturer: type: string numberOfSIMCards: type: number kind:
string
Product
--------------------
Notebook Phone
--------------------
---
Notebook
--------------------
manufacturer: String numberOfUSBPorts: int
--------------------
---
Phone
--------------------
manufacturer: String numberOfSIMCards: int
## Mutations and Input Types
_Mutations_ are operations you use to add, update, and delete data objects. In GraphQL, mutation
operations represent the POST, PATCH, PUT, DELETE, and HTTP methods that you’ve defined in your REST
API specification.
For example, this RAML specification defines a POST endpoint at `/createOrder/{OrderInput}`, and the
mutation method in the schema is `createOrder(input:OrderInput)`:
RAML API Specification
API Schema
#%RAML 1.0
title: Order API
/createOrder/{OrderInput}: post: displayName: Create Order by
OrderInput
createOrder(input:OrderInput):
Order
Input types represent the attributes of objects created by mutation operations. Input types are
POST, PUT, and DELETE request objects you use to modify information in your unified schema when you
run mutations.
For example, you can post to the `OrderInput` input type using the `/createOrder/{OrderInput}:`
mutation:
createOrder (input: “123”) { orderId customerEmail cutomerID orderDate product status totalAmount }
## Additional Resources
- [Writing GraphQL Queries and Mutations in DataGraph](https://docs.mulesoft.com/datagraph/write-queries-tutorial)
- [Anypoint DataGraph Quick Start Guide](https://docs.mulesoft.com/datagraph/datagraph-qsg)