Creating APIs and applications

You can develop API proxies and API implementations by using the developer toolkit. In the documentation, API refers to the API proxy and application refers to the API implementation.

You can use the developer toolkit to create language-independent APIs by using OpenAPI to proxy to an existing backend implementation or to augment applications that are developed in other languages or frameworks such as Express, Java™, Swift, Go, and others.

Creating development artifact definitions

Use the apic create command to create development artifacts, by using the following commands:

Command	Description
`apic create:api`	Create an OpenAPI definition.
`apic create:api --wsdl filename`	Create a SOAP API definition from a WSDL definition file, or a .zip file that contains the WSDL definition files for a service. The name and version of the generated API are obtained from the WSDL file. If you upload a .zip file, you can include in the .zip file an options file to specify additional directives. For details, see Using an options file when importing a WSDL service.
`apic create:product`	Create an API Product definition.

Note: You can create an API or Product from an OpenAPI template file by using the --template template-name option.

You can also create Product and API definitions non-interactively by providing the --title option. This option sets several values that you can also customize with additional options; for example:

apic create:api --title Routes
apic create:product --title "Climb On"

You can also create the API and Product definitions at the same time:

apic create:api --title Routes --product "Climb On"
apic create:api --wsdl globalweather.wsdl --product "Weather Forecasting"

Alternatively, you can create APIs and then reference them when you create a new Product; for example:

apic create:api --title Routes
apic create:api --title Ascents
apic create:product --title "Climb On" --apis "routes.yaml ascents.yaml"

Validating development artifact definitions

After you edit development artifacts or before you publish artifacts, best practice is to validate them; for example:

apic validate routes.yaml                      # Validate an API
apic validate climb-on.yaml                    # Validate the Product and its APIs
apic validate climb-on.yaml --product-only     # Validate the Product only (do not validate the referenced APIs)

Note: If the OpenAPI file that defines your API uses a $ref field to reference a fragment of OpenAPI code that is defined in a separate file,the $ref field is replaced with the contents of the target file before the draft API is created with the apic drafts:validate command. For more information, see Using $ref to reuse code fragments in your OpenAPI files.