Document Components

In this document, you'll learn how to register and use OpenAPI components in your application's documentation.
Registering Components with APIDocumentContext
When your application is being documented, a single instance of APIDocumentContext is created and passed to every documentation method. The context stores the document being created, but more importantly, is a container for reusable components. You may register components by implementing APIComponentDocumenter and implementing its abstract method. For example, the following code registers a reusable schema object:
1
class SourceRepository implements APIComponentDocumenter {
2
  @override
3
  void documentComponents(APIDocumentContext context) {
4
    super.documentComponents(context);
5
​
6
    context.schema.register("SourceRepository",
7
        APISchemaObject.object({
8
          "id": APISchemaObject.integer(),
9
          "name": APISchemaObject.string()
10
        });          
11
  }
12
}
Copied!
A "SourceRepository" is an object that contains two fields, "id" (an integer) and "name" (a string). This component can be used anywhere a schema object can be used. Schema objects are one type of component that document what is typically considered to be a 'model object'. You most often see schema objects in request and response bodies. By default, each of your ManagedObjects are registered as schema objects. The other types of components are: responses, request bodies, parameters, headers, security schemes, and callbacks.
Components must be registered with a name, but can additionally be registered with a type. This allows users of a component to reference it by its Dart type. Including a type reference for an object is an optional argument when registering.
1
context.schema.register("SourceRepository",
2
    APISchemaObject.object({
3
      "id": APISchemaObject.integer(),
4
      "name": APISchemaObject.string()
5
    }, representation: SourceRepository);
Copied!
The order in which components are registered and referenced does not matter. If you reference a component that is created later in the documentation process, it will be resolved prior to the document being completed. If a referenced component is never registered, an error is thrown and your document will fail to generate.
Using Components
Components can be used when declaring path operations, or as part of other components. For example, if you were to describe a response whose body was a component named "SourceRepository", it would look like this:
1
class RepositoryController extends ResourceController {
2
  ...
3
​
4
  @override
5
  Map<String, APIResponse> documentOperationResponses(APIDocumentContext context, Operation operation) {
6
    if (operation.method == "GET") {
7
      return {
8
        "200": APIResponse.schema(context.schema["SourceRepository"])
9
      };
10
    }
11
    return null;
12
  }  
13
}
Copied!
If an object has been registered by its type, you may use getObjectWithType.
1
class RepositoryController extends ResourceController {
2
  ...
3
​
4
  @override
5
  Map<String, APIResponse> documentOperationResponses(APIDocumentContext context, Operation operation) {
6
    if (operation.method == "GET") {
7
      return {
8
        "200": APIResponse.schema(context.schema.getObjectWithType(SourceRepository))
9
      };
10
    }
11
    return null;
12
  }  
13
}
Copied!
Component Discovery
All controllers are can document components when they are linked to the entry point. Objects other than controllers will automatically document their components if they implement APIComponentDocumenter and are declared properties of your ApplicationChannel. (See this guide for other options.)
Built-in Conduit types will register any applicable components. This includes the types that handle OAuth2 as well as all ManagedObject subclasses in your application.
ManagedObject Discovery
Declaring a ManagedContext as a property of your ApplicationChannel will automatically document the managed objects of your application as schema components.
Serializable Discovery
If a Serializable object is bound to a request body in a ResourceController, it will automatically be documented as a schema component. By default, the properties of the Serializable object are reflected on to produce this component. To override this behavior and provide your own component documentation, implement the following method in your Serializable subclass:
1
class Person extends Serializable {
2
  String name;
3
​
4
  Map<String, dynamic> asMap() => {"name": name};
5
  void readFromMap(Map<String, dynamic> map) {
6
    name = map['name'];
7
  }
8
​
9
  APISchemaObject documentSchema(APIDocumentContext context) {
10
    return APISchemaObject.object(properties: {
11
      "name": APISchemaObject.string()
12
    });
13
  }
14
}
Copied!
If you Serializable type is not bound to a resource controller operation, you must register it yourself. This typically occurs by overriding documentComponents in the controller that uses the type.
1
class MyController extends ResourceController {
2
  ...
3
​
4
  @override
5
  void documentComponents(APIDocumentContext context) {
6
    super.documentComponents(context);
7
​
8
    final personSchema = Person().documentSchema(context);
9
    context.schema.register(
10
      "Person",
11
      personSchema,
12
      representation: Person);          
13
  }
14
}
Copied!
OpenAPI
Documenting Endpoint Controllers
Last modified 6mo ago
Copy link
Contents
Registering Components with APIDocumentContext
Using Components
Component Discovery
ManagedObject Discovery
Serializable Discovery