Data sync is done. Data processing is complete. The final table has landed in the database.
But for the business systems that actually need this data, that's usually not the end of the story.
Dashboards, business applications, or third-party systems can't each directly connect to the database, understand the underlying table structure, and write their own SQL queries. For a data middle platform, beyond solving how to bring data in and how to process it, there's one more question:
How do you deliver processed data in a standardized, controlled way?
qData Open Source Edition provides API management capabilities within its data service module. It lets you configure database tables, SQL queries, or forwardable data assets into callable APIs — complete with parameter configuration, interface testing, application authorization, and call record management.
In this article, we'll walk through the most straightforward scenario: how to turn a ready-to-use database table into a callable data API step by step in qData.
Before You Start: Prepare the Data You Want to Serve
Let's say your database already has a hydrological monitoring data table containing fields like:
- Station code
- Station name
- Monitoring time
- Water level
Now you want to expose an interface to external business systems so callers can query water level data by station code.
Before creating the API, confirm two prerequisites:
- The target data source and database table are accessible and working properly.
- You've already set up a service category under Data Service > Service Categories for this API.
qData's service categories support a parent-child hierarchy for organizing different data services. Enterprises can pre-build categories based on business domain, data type, or system purpose. Once APIs are created, they can be found and maintained under a unified directory.
Once data preparation is done, you're ready to enter the API creation flow.
Create the API: Configure a Data Table as a Data Service
Go to Data Service > API Management and click "New".
qData uses a three-step flow to create APIs:
Property Configuration → Parameter Configuration → Testing
These three steps essentially answer three questions:
- What is this API?
- Where does the data come from, and what parameters are passed when calling it?
- Does the API return results correctly after configuration?
Step 1: Configure Basic API Properties
The first step is Property Configuration. Here you define the API's core information:
- API category
- API name
- API endpoint path
- API version
- Request method
- Response format
- API description
You can also configure management controls as needed:
- IP blacklist
- Request rate limiting
- API online/offline status
For example, in the hydrological monitoring scenario, you might define this as a "Water Level Daily Report Query Service," specifying the API path, version, POST method, and a business description.
These properties serve both internal platform management and communicate to future callers what this API does and when to use it.
If there are call frequency limits, you can set rate limiting. If certain IPs should be blocked, you can control that via the IP blacklist.
Once basic properties are confirmed, move on to parameter configuration.
Step 2: Select the Data Table and Define "How to Query, What to Return"
In Parameter Configuration, you first determine where the API's data comes from.
qData currently offers three configuration modes:
- Single-table wizard
- SQL script mode
- Third-party forwarding
For our single-table scenario, select the corresponding data source, then choose the table you prepared earlier. This tells the platform: "This API's data comes from this table."
But selecting a table doesn't mean exposing the entire database table directly to business systems.
When serving data externally, you need to define two things:
01 — What conditions can callers use to query?
For example, if you want business systems to query water level data by station code, add a request parameter station_code in the Request Parameters section, and configure:
- Whether it can be empty
- Parameter type
- Parameter description
- Example value
- Default value
This way, callers only need to pass in a station code to query the corresponding station's data.
02 — What fields can callers actually receive?
After defining request conditions, configure the response fields. For example, you might select:
- Station code
- Station name
- River name
- Water level
So turning a database table into an API isn't about exposing the raw table structure. The platform lets you precisely define what callers can query by and what data they ultimately receive.
Step 3: Test the API Online Before Delivery
After parameter configuration, it's not recommended to hand the API over to business systems immediately. Run it once in qData first.
In the Testing step, the page displays:
- API name
- Version
- Request method
- Response format
- Call endpoint
It also provides a request data input area. Fill in the request parameters you defined, then click "Call API".
If the request succeeds, the platform shows a successful call and displays the actual query results in the response area. If a required parameter is missing, it will prompt that the parameter cannot be empty.
During this phase, focus on confirming three things:
- Do the query conditions actually take effect?
- Are the returned fields correct?
- Does the actual returned data match expectations?
After testing, the API enters the API management list. You can re-verify later by going to the API details and using "Test Info" to trigger another call.
At this point, the database table has essentially completed its transformation from "table" to "API." But to let other business systems actually use it, you still need to handle access identity and authorization.
Create a "Caller Identity" for Business Systems
Once the API is created, not just any system can access it by grabbing the endpoint URL.
In qData, business systems that actually call the API need to first establish an application identity through Application Management.
Go to Data Service > Application Management and create a new application.
For example, if a water resource monitoring system needs to call the API you just created, register it as an application in qData and maintain:
- Application name
- Application type
- Application description
This answers the question: Who is using this API?
For enterprise data services, this matters because the API itself is a data capability, but the actual callers are usually frontend apps, business systems, upstream platforms, or third-party integrations. Only by identifying the caller first can you then control which data services each application is allowed to access.
Authorize the Application to Access the API
After creating the application, it doesn't automatically gain access to all APIs.
Go to API Authorization in the application details, click "New", select the API you created earlier, and set the authorization validity period.
qData supports:
- Permanent validity
- Specified start and end dates
After submission, the API appears in the application's authorization list.
This creates a clear mapping in the platform: which application can call which API.
When your enterprise grows to dozens of business applications and hundreds of data APIs, this relationship becomes critical. Different business systems can each maintain their own allowed data services, rather than opening all APIs indiscriminately to every caller.
Get Access Credentials and Let Business Systems Call the API
Once the application identity and API authorization are in place, you're ready for actual system integration.
Business systems need to obtain an access token according to the authentication method configured in your qData deployment environment, and include the valid token when calling specific business APIs.
From the business system integration perspective, the complete flow is:
Create Application → Obtain Application Identity → Authorize API → Get Token → Call API with Token
At this point, the way business systems access data has fundamentally changed.
Before: Direct database access.
Now: Call APIs through the data service layer to retrieve data.
The database tables still serve as the underlying data store, but business systems no longer need to understand the database structure directly. They query through the platform's data service layer.
Track API Calls After They Happen
Once APIs go live in production, the management work doesn't end. You'll quickly face practical questions:
- Has the API been called?
- Who called it?
- How much data was returned?
- Why did a particular call fail?
qData provides unified call tracking under Data Service > Call Records, where you can view:
- API service name
- Caller IP
- Called endpoint
- Data volume returned
- Response time
Drilling into details, you can further inspect:
- Call parameters
- Request method
- Call status
- Error information
For example, when a business system reports "this API didn't work just now," operations or development staff can locate the corresponding request by service name and call time, then review the parameters, status, and error details.
This means the API isn't just a configured interface handed off and forgotten — it has a complete lifecycle from creation, authorization, and invocation to ongoing tracking.
From Table to API: The Full Flow at a Glance
Looking back, the entire process from a prepared database table to a live, callable API can be summarized as:
Prepare Data Table → Create API → Configure Properties → Select Data Table → Configure Request Parameters and Response Fields → Test Online → Create Calling Application → Authorize API → Obtain Access Credentials → Business System Calls API → Review Call Records
This pipeline reflects a fundamental challenge in data middle platforms: syncing data in and processing it only covers the first half of data construction.
The real business usage phase requires answering: How do you deliver processed data securely and clearly to other systems?
qData Open Source Edition's data service module adds a data service capability layer between database tables and business applications.
The underlying storage remains the database tables you've already built, but when serving externally, you can further define interfaces, query parameters, response fields, application identities, and authorization relationships.
This transforms a table that could previously only be queried inside the database into a data API callable by business systems.
Wrapping Up
For enterprise data middle platforms, data doesn't create real business value just by being "synced" or "processed."
What matters more is how you deliver that prepared data to dashboards, business systems, and third-party applications.
qData Open Source Edition achieves this through:
API Creation → Parameter Definition → Online Verification → Application Identity → API Authorization → Token-based Calls → Call Records
This progressively converts a raw database table into a data service usable by business systems.
It's not simply wrapping an interface around a table. It's establishing a clear service boundary between data and business applications — defining where data comes from, how it can be queried, what can be returned, who can call it, and how calls are tracked afterward.
Extending from "bringing data in and managing it" to "delivering data out and putting it to real use" — that's the practical significance of qData's data service within the broader data middle platform pipeline.
Top comments (0)