Benefits

Generates source codes

You can turn your API concepts into reality using the Catalyst ZEST Specification Format (ZSPEC). You can obtain backend source code (this includes the required classes, files, and dependencies) for Catalyst AppSail and Functions. Using this generated boilerplate code, the developer can add the code for business logic through Catalyst AppSail and Functions. This tool simplifies workflows and speeds up the progress of your development projects.

Generates SDKs

You can bridge the gap between your APIs and developers across the world with the Catalyst ZEST generated SDKs. This tool broadens the horizons of your APIs across different languages and platforms with just one click. It generates precise SDKs in multiple languages based on your ZSPEC configurations.

Automates Automation

Catalyst ZEST builds the essential test cases based on your ZSPEC architecture and runs them to provide reports whenever the developers need. It also identifies and captures unhandled errors in your architecture, contributing to the development of a flawless API.

Creates comprehensive Document

Using ZEST, you can download a meticulously crafted and detailed three-pane document for your APIs. Every structure and response configured in the ZSPEC will get documented with samples. This makes the help document a one-stop solution for all user questions and concerns.

Supports available in ZSPEC

ZSPEC file is an XML format and enables you to define specifications in a single file. It includes host configurations like the API endpoints needed by the user, the properties of the resource, inputs for source code, automation, and help documentation. The ZSPEC Format is the super-set of OAS 3.0 and it has the below additional supports.

1.1. Enable automated quality check using ‘Extra Value Validation’

Use Case

Consider a field Department with the list of possible values as “Mechanical”, “Electronics”. and “Computer Science”.

Scenario 1: Permit the new value

When the user enters a value as “Civil” (other than these three values), the requirement is to allow the new value. Here, the requirement is to allow additional values for the field Department.

Scenario 2: Deny the new value

When the user enters a value as “Civil” (other than these three values), the requirement is to deny the new value. Here, the requirement is to deny additional values for the field Department and show error.

Scenario 3: Assign a default value

When the user enters a value as “Civil” (other than these three values), the requirement is to assign a default value. Here, the requirement is to ignore the new value and assign a default value for the field Department. In these scenarios, the requirement is to handle additional values for the field Department and all these can be achieved using ZEST Specification Format but not using OAS 3.0. ZSPEC enables you to handle additional values for a particular property. The possible values are map-default, deny and allow.

1.2. Achieve Tailored API Interactions using ‘Conditional Requests and Responses’

A. Condition for Request

Use Case

Consider the fields Country, Postal Code, and Zip Code. The requirement is: Whenever the Country is “India”, then you have to construct the request body with Postal Code and whenever the Country is “US”, then you have to construct the request body with Zip Code.

Here, the requirement is to construct the request body based on the value of Country. This use case can be achieved using ZEST Specification Format, but not using OpenAPI 3.0. ZSPEC enables you to construct the body of the request based on custom criteria.

B. Condition for Response

Use Case

Consider the fields Country, Zip code, and Zip Code. The requirement is: If the Country is “India”, then you need to validate whether the response has Zip code and if the Country is “US”, then you need to validate whether the response has Zip Code. Here, the requirement is to validate the response based on the country. This use case can be achieved using ZEST Specification Format but not using OpenAPI 3.0. ZSPEC enables you to validate the response to match the criteria.

1.3. Ensure Data Integrity with ‘Invalid Value Validation’

Use Case

Consider the field “Username” in a SignUp Form. Let’s say you have defined the criteria for valid usernames - Should be unique - Minimum length should be 9 - Should not begin with special characters.

Scenario 1: Assign a default value

If the username doesn’t meet these criteria, the requirement is to assign an auto-generated username that meets your criteria. Here, the requirement is to assign a default value to the Username field.

Scenario 2: Deny the value

If the username doesn’t meet these criteria, the requirement is to deny the value. Here, the requirement is to deny the value that does not meet your criteria.

In the above scenarios, there is a need to check if the values are in line with your criteria and handle them by assigning a default value or denying the value. This use case can be achieved using ZEST Specification Format but not using OpenAPI 3.0. ZSPEC enables you to handle values that do not satisfy your criteria by assigning a default value or denying the value.

1.4. Effortless Data Retrieval using ‘DataPath Property’

Use Case

In Zoho CRM, there is a set of standard modules along with the custom modules that every account has. While handling an API, say you want to fetch the list of API names of all modules. Here, the requirement is to pick values from a particular path. This use case can be achieved using datapath= $.modules.API_Name in the ZEST Specification Format.

ZSPEC enables the API to fetch the values from a specified path.

1.5. Achieve data completeness ‘Emptiable Property’

Use Case

Consider an organization where every employee will have an Employee ID. You don’t want to allow empty values in this field. Here, the requirement is to deny empty values in the field Employee ID. This use case can be achieved using ZEST Specification Format but not using OpenAPI 3.0.

You can allow or deny empty values in all requests and responses of an API.

1.6. Maintain data distinction with ‘Unique Property’

Use Case

Consider an organization where every employee will have an Employee ID. You don’t want to allow duplicate values in this field. Here, the requirement is to deny duplicate values in the field Employee ID. This use case can be achieved using ZEST Specification Format but not using OpenAPI 3.0.

You can define whether values in all requests and responses of an API should be unique or not.

1.7. Customize validation using ‘Include-for Property’

Use Case

Consider the “email” field in a SignUp Form. The requirement is that you only want to perform email validation during the account creation operation. However, during other operations like updating customer details, email validation is not required. Here, you want to enable the validation for email only during create operation of REQUEST. This use case can be achieved using ZEST Specification Format but not using OpenAPI 3.0.

Using ZSPEC, you can perform validations only for specific operations of request or for specific operations of response.

1.8. Fortify your API’s structure with ‘Additional Property Name and Value Validation’

Use Case

Consider a scenario similar to variables in CRM. The requirement is to restrict the maximum length of the name to 15 and the value to 50. Here, the requirement is to allow additional variables but imposing restrictions to the length of the value these variables hold.

Using ZSPEC, you can allow additional properties and add constraints to the name and value these properties hold.