This page documents what type definitions in TypeSpec would look like when returned by TCGC
Main TypeSpec Code Example
Overall Hierarchy of Types
This is a rough sketch of the hierarchy. We’ll go into more detail for each section, this is just to get an idea of the overall structure.
SdkContext
SdkContext is the context of your SDK emitter.
Interface
Usage
It is used to persist information across functions. You should never define global constants or variables in your emitter code, because this leads to issues with multiple emitter runs. Instead, all global information should be stored in your context.
You should define your own language-specific SdkContext that extends from the one defined in @azure-tools/typespec-client-generator-core. This is where you keep your global variables. You should utilize the createSdkContext from tcgc.
You also shouldn’t instantiate your own interface, instead you should call createSdkContext to create.
SdkPackage
SdkPackage represents the entire package that your language emitter should generate. It synthesizes all of the information language emitters will need to generate the entire package
Interface
Example
Usage
SdkClientType
An SdkClientType represents a single client in your package.
All clients will have an initialization property. Whether that property’s access is internal or public will determine whether your client can be publicly instantiated or not.
Interface
Example
Usage
SdkInitializationType
Initialization model for a client. Whether it’s access is public or internal tells you whether the client is publicly instantiable.
Interface
Example
Usage
The usage of this property is more language-dependent.
Some emitters will create a model and have the client accept the model as options to initialize your client. Others will flatten out the parameters and accept them individually as parameter input.
SdkMethod
An SdkMethod is any of the types of methods that can be a method on a client.
There are two main types of an SdkMethod:
SdkClientAccessor returns a subclient of the client it’s on
SdkServiceMethod wraps a service call
They each extend from the shared SdkMethodBase
Below we go into each method type
SdkClientAccessor
A clientaccessor method is simply a method on a client that returns another client. The returned client can be instantiable or un-instantiable. If the returned client is instantiable, most likely your clientaccessor will be part of the public api surface, so users can instantiate the subclient using your client method. If it is not instantiable, it is up to you how to expose the subclient on your current client for users to access.
Interface
Example
Usage
Our strong recommendation is you build up a list of clients by iterating through sdkPackage.clients first, and to not recurse into creating the subclients.
Only once you’ve processed each client, then you go through and link clients to their subclients. Not doing recursion prevents confusion over where you are in the call chain.
SdkServiceMethod
An SdkServiceMethod is any service method on a client that calls the service.
The actual service call is a separate property on the method, .operation. This way, our service methods are able to abstract away the protocol used to call the service (i.e. http or gRPC)
All SdkServiceMethods share the following base:
SdkBasicServiceMethod
This models a basic service call that is synchronous server side.
Interface
Example
Usage
SdkPagingServiceMethod
This represents a paging method we will generate on the client. It includes an initial service operation call, and potentially a next link operation as well.
We currently only have paging method support for azure-generated sdks.
Interface
Example
Usage
SdkLroServiceMethod
Represents an LRO method we want to generate on the client.
Only returned for azure-generated sdks
Interfaces
Example
Usage
SdkLroPagingServiceMethod
This is a combination of Lro and paging. We start off with an LRO call to the service, and then the response is returned to us in pages. Also only available for azure-sdks.
Interface
Usage
SdkServiceOperation
One main part of this design is we’ve decoupled the actual service operation call from the method we generate on our client. This is because we want to abstract away the protocol used to call our service. Additionally, while there is a high level of correlation between the method parameters we intake from SDK users, and the parameters we end up passing the service, it’s not one-to-one. We need to serialize the method parameters and additionally, when parameters are spread or grouped together, it requires us to do mapping between which method parameters correspond to which service parameters.
We currently only support HTTP calls to the service.
Interface
Example
Usage
Parameters and Properties
Like the TypeSpec concept of a ModelProperty, all properties and parameters are part of the SdkModelPropertyType. They all extend from SdkModelPropertyTypeBase.
Method parameters
These are parameters to client initialization and method son the client. These will be the parameters that SDK users directly use. They will eventually be mapped to
SdkEndpointParameter
An SdkEndpointParameter represents a parameter to a client’s endpoint.
TCGC will always give it to you as overridable:
If the server URL is a constant, we will return a templated endpoint with a default value of the constant server URL.
In the case where the endpoint has extra template arguments, the type is a union of a completely-overridable endpoint, and an endpoint that accepts template arguments.
If there are multiple servers, we will return the union of all of the possibilities.
SdkCredentialParameter
Parameter for credential input to clients.
SdkMethodParameter
Represents a parameter to a client method. Does not have any transport (i.e. HTTP) related information on it. This is solely meant to represent information that we expect sdk users to pass in. We then take care to map the method input and create our request to the service using the information users have inputted.
Service Parameters
Currently we only support HTTP service parameters.
SdkQueryParameter
This represents an HTTP query parameter.
SdkHeaderParameter
This is an HTTP header parameter.
SdkPathParameter
SdkBodyParameter
Properties
SdkBodyModelPropertyType
This represents a property on a body model
Usage
We recommend that for usage, you use one single function with switch statements for each kind of property.
This allows for the circular nature of an SdkModelPropertyType.
SdkMethodResponse
This represents the response that our method will ultimately return.
It is not tied to a transport, like http, it solely represents what we want to return to users
Interface
Example
Usage
SdkHttpResponse
This is the response returned from an HTTP service. The emitters should take care to map it to what the method ultimately returns to end users.
Each response is mapped to an HttpStatusCodeRange on the SdkHttpOperation interface.
Interface
SdkType
These are the TCGC versions of each TypeSpec Type. They include information that all emitters want, i.e. their description directly on them.
They all share this base:
SdkBuiltInType
A SdkBuiltInType represents a built-in scalar TypeSpec type or scalar type that derives from a built-in scalar TypeSpec type, but datetime and duration are not included.
We add encode onto these types if @encode decorator exists, telling us how to encode when sending to the service.
There is a one-to-one mapping between the TypeSpec scalar kinds and the SdkBuiltInKinds.
Interface
The crossLanguageDefinitionId represents the fully qualified name of this type in TypeSpec language for the emitter to distinguish from the built-in TypeSpec types.
For a full list of types defined in @azure-tools/typespec-azure-core library, please refer to its reference doc.
SdkDateTimeType
SdkDurationType
SdkArrayType
SdkDictionaryType
SdkEnumType
SdkEnumValueType
SdkConstantType
SdkUnionType
SdkTupleType
SdkModelType
UsageFlags
AccessFlags
We default the value of .access property on model, enum, and method types to be "public". So if the @access decorator isn’t explicitly applied to one of these definitions, its value will be "public".
If you want to know if a tsp author explicitly set the value with an @access decorator, you can call getAccessOverride
SdkEndpointType
Example Types
The example types help to model the examples that TypeSpec author defined to help user understand how to use the API.
We currently only have examples based on the payload, so the examples model will bind to the SdkServiceOperation.
Operation Related Interface
These types are used to represent an example of a service operation.
We currently only support HTTP calls to the service.
So, we have SdkHttpoperationExample bind to SdkHttpOperation, SdkHttpParameterExampleValue bind to SdkHttpParameter, SdkHttpResponseExampleValue bind to SdkHttpResponse, and SdkHttpResponseHeaderExampleValue bind to SdkHttpResponseHeader.
Each type will have the example value type and its cooresponding definition type.
SdkExampleValue
These types are used to represent the example value of a type. One definition types will have different example value types.
For SdkUnionExampleValue, since it is hard to determine whether the example value should belong to which union variant, we will keep the raw value and leave the work for the emitter.
For SdkModelExampleValue, we will help to map the example type to the right subtype for the discriminated type, and we will separate the additional properties value from the property value.
But for the model with inheritance, we will not break down the type graph, just put all the example value in the child model.