DataService Studio lets you create data APIs from existing data sources using the codeless UI or the code editor. This topic provides a walkthrough of creating an API with API Gateway. You will learn how to enable API Gateway, create a business process, and generate and configure an API.
For the cloud-native API Gateway, see Create, publish, and invoke an API (cloud-native API Gateway).
Prerequisites
You have configured a data source on the page. For details, see Configure a data source.
The data service requires a resource group. In a production environment, we recommend using a serverless resource group. For details, see Resource groups and network connectivity.
DataService Studio
Log on to the DataWorks console. In the top navigation bar, select the desired region. In the left-side navigation pane, choose . On the page that appears, select the desired workspace from the drop-down list and click Go to DataService Studio.
Step 1: Set up API Gateway
Before you create a business process, complete the following tasks on the API Gateway console.
Log in to the API Gateway console and enable API Gateway.
On the API Gateway console, create an API group. An API group is a collection of APIs for a specific feature or scenario. It is the basic management unit for APIs in API Gateway.
ImportantThe API Gateway region must match the DataWorks workspace region.
Step 2: Create a business process
The data service uses business processes to organize API development by business domain. Each business process must be bound to an API group. Before you can generate an API, you must create a business process.
On the Service Development page, click the
icon and select Create Workflow.In the Create Workflow dialog box, configure the parameters.
Parameter
Description
Workflow Name
The name must be unique within the workspace. It must be 4 to 50 characters long, start with a letter or a Chinese character, and can contain Chinese characters, letters, digits, and underscores (_).
API grouping
Select the API group that you created in Step 1. To create a new group, go to the API Gateway console.
ImportantAfter you bind a business process to an API group, you cannot change the group. Select the group carefully.
Business Description
Enter a description for the business process. The description cannot exceed 180 characters.
Click Determine. After the business process is created, you can view it in the Workflow list.
Step 3: Choose an API mode
Data Service lets you create APIs in wizard mode or script mode. Both modes share the same basic API configuration process but they differ in how you build query logic.
Mode comparison
Feature category | Feature | Wizard mode | Script mode |
Query object | Querying a single data table from a single data source | Supported | Supported |
Multi-table JOINs in a single data source | Not supported | Supported | |
Query conditions | Equality, range, and fuzzy match queries | Supported by selecting an operator | Supported by defining custom SQL |
Dynamic MyBatis conditions (such as optional parameters) | Not supported | Supported in Advanced SQL Mode | |
Query results | Returning raw field values and paginating results | Supported | Supported |
Mathematical operations and aggregate functions | Not supported | Supported |
Choosing a mode
Use wizard mode: for simple queries on a single data table, such as equality, fuzzy match, or range filtering. This mode provides a visual, no-code interface for API configuration.
Use script mode: for advanced queries, such as multi-table JOINs, nested subqueries, aggregation, or dynamic conditions with optional parameters.
You can convert an API from wizard mode to script mode, but you cannot revert this change. For more information, see Appendix: Convert from wizard mode to script mode.
Step 4: Generate an API
On the Service Development page, hover over the
icon and click .Alternatively, open the relevant business process, right-click API, and choose .
In the Generate API dialog box, configure the parameters.
Parameter
Description
API Mode
Select Wizard Mode or Code Editor. If you select script mode, you must also select an SQL Mode (Basic SQL or Advanced SQL).
Basic SQL: Write query logic using basic SQL syntax.
Advanced SQL: Write query logic using SQL syntax that supports MyBatis tags. The supported tags include if, choose, when, otherwise, trim, foreach, and where.
API Name
The name can contain Chinese characters, letters, digits, and underscores (_). It must start with a letter or a Chinese character and be 4 to 50 characters long.
APIPath
The endpoint path of the API. This is the request path relative to the service host, such as /user. The path can contain letters, digits, underscores (_), and hyphens (-). It must start with a forward slash (/) and be up to 200 characters long.
Protocol
Supports HTTP and HTTPS.
To call the API over HTTPS, you must publish it to API Gateway, bind a custom domain, and upload an SSL certificate in the API Gateway console. For more information, see Support for HTTPS.
Request Method
Supports GET and POST.
NoteIf you select GET, the request parameter location must be QUERY. If you select POST, this location can be QUERY or Body.
Response Type
Only JSON is supported.
Visible Scope
Work space: The API is visible to all members of the current workspace.
Private: The API is visible only to its owner. Authorizing other users is not currently supported.
Tag
Select up to five tags from the list. Each tag can be up to 20 characters long. For more information, see Create and Manage API Tags.
Description
Enter a brief description for the API. The description cannot exceed 2,000 characters.
Location
Select an existing business process to store the API. The default path structure is "business process/Business Process Name/API".
Click Determine to open the API editing page.
Step 5: Configure the API
1. Select a data source and table
Double-click the API to open its edit page. In the Table area, configure parameters such as Data Source Type, Data Source Name, and Data Source Environment. Configuration parameters vary by data source type. Refer to the UI for the specific parameters.
You must first configure a data source in . The data table drop-down list supports searching by table name.
In script mode, you must first select a data source. You can only perform multi-table JOIN queries within the same data source.
In a standard mode workspace, you can use the Data Source Environment parameter to access data sources in either the development or production environment. For more information, see Differences between workspace modes.
For MaxCompute data sources, you can use the DataWorks DataService Acceleration Service or the MaxCompute MCQA feature to accelerate queries. To use the acceleration service, you must first create an acceleration item. For more information, see Acceleration service.
2. Define the query logic
You define query logic differently in wizard mode and script mode.
Wizard mode: select parameters
After you select a data table, all fields of the table are automatically displayed in the Select Parameters area. Select the Set as Req Param and Set as Resp Param checkboxes for the fields you need.
To sort the query results, click the Sort button next to a field to add it to the sort list. You can add multiple fields to the list. The sequence number determines the priority, with smaller numbers indicating higher priority. You can adjust the priority by using the Move Up and Move Down buttons. For each field, you can select Ascending order or Descending order.
If the data source type is HBase, the Select Parameters area displays all column families in the table. To query by column name, you must click the Add column button for a column family to manually add the desired column name.
Script mode: write query SQL
In the Edit Query SQL area, enter a query SQL statement.
Basic SQL mode: Use ${paramName} to mark request parameters. The fields after SELECT are response parameters, and the ${param} in the WHERE clause is a request parameter.
Follow these rules when you write SQL statements:
Single-table queries, multi-table JOIN queries, and nested queries within the same data source are supported.
Multiple SQL statements, comments, and non-SELECT syntax such as
INSERT,UPDATE, orDELETEare not supported.SELECT *is not supported. You must explicitly specify the columns to query.If a column name includes a table prefix (for example, t.name), you must assign it an alias (for example, t.name as name). You must also assign an alias for aggregate functions.
Placing ${param} in quotation marks is not supported. To concatenate strings, use
concat('abc', ${xyz}, '123').Basic SQL mode does not support setting parameters as optional.
Advanced SQL mode supports MyBatis tag syntax (for example, if, choose, when, otherwise, trim, foreach, and where), which allows you to flexibly implement complex query logic such as null value validation, multi-value iteration, dynamic table queries, and dynamic sorting. For code samples of common scenarios, see Appendix: Advanced SQL (MyBatis syntax) examples.
When you use special characters in Advanced SQL mode, you must escape them:
Special character | Escape character | Description |
> | > | Greater than |
>= | >= | Greater than or equal to |
< | < | Less than |
<= | <= | Less than or equal to |
& | & | And |
' | ' | Single quotation mark |
" | " | Double quotation mark |
3. Configure request parameters
Click Request Parameters in the right-hand pane of the API edit page to configure the parameters.
Before you preview the results, set the sample value, default value, and description for the API parameters.
For best performance, use indexed fields as request parameters.
In Advanced SQL mode, the system cannot automatically parse parameters. You must manually add all request parameters to the list based on your SQL script.
Wizard mode does not support creating a value range for a field by using two parameters. Use script mode for this functionality.
Parameter | Description |
Parameter Name | The name can contain letters, digits, underscores (_), and hyphens (-). It must start with a letter and be up to 64 characters long. |
Bound Field | This parameter is visible only in wizard mode and is read-only by default. It is bound to the selected data table field. To modify the binding, use script mode. |
Parameter Type | Supported types: STRING, INT, LONG, FLOAT, DOUBLE, and BOOLEAN. |
Parameter Position | QUERY or BODY. If you select BODY, you must set the Content-Type. Supported formats are JSON, XML, and FORM. |
Operator | This parameter is visible only in wizard mode. It defines the comparison operator for the parameter. Supported operators include: =, LIKE, IN, NOT IN, NOT LIKE, !=, >, <, >=, and <=. Note When the data source type is Table Store, only the = operator is supported. |
Required | Specifies whether the parameter is required for API calls. |
Sample Value | A sample value for the request parameter. |
Default Value | The default value for the request parameter. |
Description | A brief description of the request parameter. |
4. Configure response parameters and pagination
Click Response Parameters in the right-hand pane of the API edit page to configure the parameter name, parameter type, sample value, and description. In Advanced SQL mode, you must manually add all response parameters based on your SQL script.
In the Advanced Settings area, specify whether to enable Pagination for Return Results:
Disabled: The API returns a maximum of 2,000 records by default.
Enabled: You can set the maximum number of records per page on the Resource Group for DataService Studio page based on the resource group type.
When pagination is enabled, the system automatically adds the following common parameters:
Common request parameters: returnTotalNum (whether to return the total number of records), pageNum (the current page number), and pageSize (the number of records per page).
Common response parameters: pageNum, pageSize, and totalNum (the total number of records).
If an API has no request parameters, you must enable response pagination.
In script mode, if an SQL statement contains a
limitclause, thelimitclause does not take effect when pagination is enabled. The pagination settings take precedence.
5. Configure filters (optional)
To preprocess request parameters or post-process query results, click Filter in the right-side navigation pane. Select the Use Pre-filter or Use Post-filter checkbox. Then, select a Function Type and choose a function. You can add multiple functions, which are executed in the order they are added. For more information about how to create and use filters, see Create an Aviator function and Create a Python function.
To use a Python function as a filter, you must first activate DataWorks Professional Edition or a higher version and use a public service resource group.
To use an Aviator function as a filter, there is no restriction on the DataWorks edition, but you must use an exclusive service resource group.
If a function does not appear in the filter drop-down list, check whether the function has been published. For more information, see Publish a function.
6. Configure service resource groups
In the right-side navigation pane, click Resource Group for DataService Studio to configure the resource group type for the API.
You can use an Exclusive Resource Group for DataService Studio or a Shared Resource Group for DataService Studio. For an exclusive service resource group, you can select a target resource group by name. A public service resource group is automatically maintained by DataWorks.
We recommend that you use a public service resource group only for testing, not in a production environment.
If the target resource group is not in the list, go to the Resource Groups page to associate the resource group with the workspace.
In the Environment Configuration area, you can set the Memory, Timeout, and Maximum Number of Data Records for a Single Request:
Timeout: The timeout cannot exceed 30,000 ms for shared API Gateway instances, or 90,000 ms for exclusive service resource groups that use dedicated API Gateway instances.
NoteThe API's response time depends on the SQL execution time. Set the timeout value high enough to accommodate this and prevent request failures due to timeouts.
Maximum number of records per page: Up to 2,000 for a public service resource group and up to 10,000 for an exclusive service resource group. The total number of results an API can return is not limited.
Step 6: Save and submit
Click the
icon in the toolbar to save the API. The selected resource group will then take effect during testing.
Next steps
Test and publish:
After configuring the API, you can test it. For more information, see Test an API.
After the test succeeds, click Submission in the upper-right corner.
On the API editing page, click Version in the right-side navigation pane. Find the version you want to publish and click Request to Publish. On the application page, the application type defaults to Publish API in DataService Studio. Enter a Application Reason and click Requested Permissions to submit your request.
NoteIf your workspace in the DataWorks Approval Center is configured with an approval workflow, the request must be approved before the API can be published. For more information, see Approval Center Overview.
After the API is published, the settings for the resource group for DataService Studio apply to all API calls.
Manage APIs: On the Service Development page, you can manage APIs by cloning or deleting them from the directory tree. On the Service Management page, you can expand the API list to view details of published APIs. For more information, see View, delete, move, clone, perform batch operations on, and search APIs by code.
Appendix: Wizard mode to script mode
You can convert an API from wizard mode to script mode:
On the Service Development page, expand the that contains the target API.
Double-click the API name to open its edit page.
In the toolbar, click the
icon.In the Prompt dialog box, click Determine.
WarningYou can only convert an API from wizard mode to script mode.
This action is irreversible.
Appendix: Advanced SQL (MyBatis) examples
These examples show how to build complex queries with advanced SQL in script mode. Replace the table names, fields, and query conditions with your own.
Example 1: Control sort order
The value of var determines the sort order.
select col01,col02
from table_name
<choose>
<when test='var == 1'>
order by col01
</when>
<when test='var == 2'>
order by col02
</when>
<when test='var == 3'>
order by col01,col02
</when>
<when test='var == 4'>
order by col02,col01
</when>
</choose>Request parameter: var (Type: INT, Required). Response parameters: col01, col02.
Example 2: Query different tables
Different values of var determine which table to query.
select col01
from
<choose>
<when test='var == 1'>
table_name01
</when>
<when test='var == 2'>
table_name02
</when>
</choose>Example 3: Dynamic WHERE clause
Query conditions are dynamically generated based on whether the list collection is empty. If list is not null, a query condition that includes the value of the area field is generated.
SELECT area_id, area, amount
FROM table_name
<where>
<if test='list!=null'>
area in
<foreach collection="list" open="(" close=")" separator="," item="area">
#{area}
</foreach>
</if>
</where>Request parameter: list (Type: STRING_LIST, Required, Example: Beijing,Hangzhou). Response parameters: area_id, area, and amount.
Appendix: Best practice — optional parameters
In many business scenarios, some request parameters need to be optional. This lets callers decide whether to provide a value for a parameter. If no value is passed, the parameter is excluded from the query conditions. This section uses the ods_user_info_d table as an example to show how to set uid as a required parameter and gender as an optional parameter.
Parameter | Type | Description |
uid | INT | User ID |
gender | STRING | Gender |
age_range | STRING | Age range |
zodiac | STRING | Zodiac sign |
Optional parameters in wizard mode
Implementing an optional parameter in wizard mode is straightforward. After selecting uid and gender as request parameters in the Select Parameters area, go to the Request Parameters panel on the right and clear the Required checkbox for the gender parameter.
Selected: You must provide a value for the parameter when calling the API. Otherwise, a parameter validation exception is thrown.
Cleared: You can choose whether to pass a value for the parameter. If you do not pass a value, the parameter is not included as a query condition.
Example Calls:
Scenario 1: Values are passed for both
uidandgender. The system executes the following query:SELECT uid, gender, age_range, zodiac FROM ods_user_info_d WHERE uid = 0016359810821 AND gender = 'Female';Scenario 2: A value is passed for
uid, but no value is passed forgender. The system executes the following query:SELECT uid, gender, age_range, zodiac FROM ods_user_info_d WHERE uid = 0016359810821;
Optional parameters in script mode
Basic SQL cannot implement true optional-parameter logic. Even if you clear the Required checkbox, the system performs a query with parameter = null if the parameter is omitted. This typically returns an empty result set instead of ignoring the condition. To implement optional parameters, you must use the advanced SQL mode.
In advanced SQL mode, use the MyBatis <if> tag to implement conditional logic:
SELECT uid, gender, age_range, zodiac
FROM ods_user_info_d
<where>
<if test='gender!=null'>
gender = ${gender}
</if>
and uid = ${uid}
</where>The
<where>tag automatically handles the WHERE keyword and removes redundant AND or OR prefixes.The
<if test='gender!=null'>tag adds the condition to the query only if you pass a non-null value for thegenderparameter.After you configure the SQL statement, manually add the
uidandgenderparameters in the Request Parameters panel on the right, and clear the Required checkbox for thegenderparameter.
The behavior is the same as in wizard mode: the gender condition is applied when a value is passed, and is ignored when omitted.
Optional parameter configuration
Method | Implementation | Complexity | Use cases |
wizard mode | Clear the "Required" checkbox. | Low | Simple, single-table queries |
script mode (basic SQL) | Not supported | — | — |
script mode (advanced SQL) | Wrap the condition in an | Medium | multi-table joins and complex queries |