Exposed API

By Default, Wizzdi Cloud generates CRUD API endpoints.  To change this behavior, select Exposed API from the menu.

Select Settings 

Then, switch off the Auto Generation option. 

Importing an Open API API specifications #

Wizzdi Cloud supports the import of Open API definitions from a URL or a file. In both cases, the definitions can be JSON-based or YAML-based.

Importing Open API specifications is the first step in the Contract First approach. Alternatively, the API endpoints can be manually defined.

Select manage at the bottom right corner of the Exposed Api section, then select the top option.

Import Open API definitions from URL into the Exposed API. #

Below is an example of an OpenAPI URL from another demo App deployed in Wizzdi Cloud Customer’s cluster, where Apps may run.

In such cases, the URL is https://[appname].[workspace].cluster.wizzdi.com/api/v3/api-docs
for example, https://publish16.avishay-s-workspace.cluster.wizzdi.com/api/v3/api-docs.

Paste the URL in the upper text box of the import OpenAPI dialog.

Here is the link

Hit the Save Changes button. After a while, you should see the endpoints in the exposed API view.

To import from a file, click Upload File and browse for a valid OpenAPI file on the local system.

Import can be executed as many times as required. Note that the import of an existing endpoint will not change its signature.
Changing the EndPoint properties can be carried out by the built-in editor provided in Wizzdi Cloud.

One needs to scroll to see all imported endpoints.

Note: We can see the endpoints if we deploy the application now. However, the endpoints are not currently linked to any actual actions. Linking the endpoints to ‘real’ actions requires the following steps:

•  Infer the required domain model from the endpoint definitions.
• Create the domain model entities, enums, and relationships.
• You must create either a Custom Query, Flow, or both for each endpoint.
• The imported API defines the request and response objects required in the Custom Queries and Flows.

Managing Exposed EndPoints. #

Once the API is imported, endpoints are visible under the corresponding tags in the OpenAPI document.

To enable an endpoint in a web application or API to perform specific actions, it must be integrated with either a Flow or a CustomQuery. A Flow refers to a predefined sequence of operations or tasks the endpoint will trigger and execute. These operations could include data processing, database interaction, calling other services, or another flow. On the other hand, CustomQuery is a user-defined operation, often tailored for complex or specific data retrieval. It usually involves using the Wizzdi Cloud custom query visual tool. By linking an endpoint to a Flow or a CustomQuery, you define the exact functionality that the endpoint will offer, essentially ‘programming’ it to respond to client requests meaningfully.

To edit an endpoint, click on the small open triangle to the right of its available tools:

An empty endpoint (POST method) below:

Adding Request object #

In a POST method, the Request Object is essential. It contains a JSON body from the client, which the server uses to retrieve,  create, or update resources.

In the example below, we will build a request object to create a family on the server.

Click on the small arrow to the right to expand the view.

Let’s create a FamilyCreate request object:

• Select the ‘Create Custom’ option ******   from the ‘+Select’ option to the right of the Request icon 

• Create a new object called FamilyCreate.  

•  Open the new object members editing by clicking on the two small arrows, first #1, then # 2 
• Proceed by clicking on the ‘+’ sign to add a member.
• Select Object here -> 
• In  the Object Creation dialog, Select the name -> Person 
• The default name for the created Person object is ‘person’; let’s use the ‘pencil’ icon to change it to Parent1 as below:
• 
• Let’s expand person1 using the small arrow to the left of its name and click on the ‘+’ sign to add two properties. A name and a birth date.
• 

Note: Adding these properties to the parent1  field in the request object changes the object Person. Other uses of the Person object are immediately affected.

• Let’s add a new parent2 field. At this time, the Person object is defined, and we will create a Property of the type Person.
• Click on the ‘+’ sign at the highest level of the Request object and select Property.  

Note: Please be cautious when selecting which ‘+’ sign you click on. In the image above, the upper ‘+’ adds fields to parent1, whereas the lower ‘+’ adds fields to the request object.

• Add the name parent2, then start typing ‘Perso’ in the Type field. When the previously defined Type becomes available, select it.
• Click on ‘Create Property’ to dismiss the dialog. 
• Once both parents are added, you should see:
• 
• Let’s add a List of children to the FamilyCreate object:
• 
• We have added a familyName to the request object. The final object is below:
•