Mastering API Full Lifecycle: From Object Modeling to Service Orchestration

API Full Lifecycle Overview

The discussion begins with the concept of an API full‑lifecycle management system that spans development, runtime, and operations phases. A lightweight API gateway focuses solely on runtime concerns, delegating protocol conversion, adaptation, and data mapping to an API development platform that registers standard HTTP APIs with the gateway.

Subsystem Decomposition

The lifecycle is split into four subsystems: the API Development Platform, the API Gateway Engine, the API Monitoring & Operations Platform, and the API Governance Platform. Traditional ESB adapters and heavy protocol conversion are moved to the development platform, while the gateway handles request routing and logging.

Object‑Driven Modeling

Core to the platform is an object‑model‑driven approach. Objects are defined as multi‑level tree structures that can generate multiple database tables, supporting decoupling and multi‑database scenarios. Modeling objects first, rather than exposing raw tables, enables flexible composition, rule extension, and consistent transaction control.

Objects automatically produce standard CRUD interfaces (POST, GET, DELETE, etc.) and can export contract files such as RAML, YAML, or WADL. The generated models can also be transformed into client SDKs for various languages and frameworks, similar to Swagger code generation.

Automatic Interface Generation

Once objects are defined, the platform can generate corresponding API endpoints. A typical set includes create, update, query, and delete operations. The open‑source xmysql tool demonstrates this by exposing an entire MySQL schema as REST APIs:

npm install -g xmysql
xmysql -h localhost -u mysqlUsername -p mysqlPassword -d databaseName
http://localhost:3000

Generated APIs lack built‑in permission controls and are intended for testing or as reference implementations. Complex queries are recommended to use POST with a request body rather than GET.

Rule Processing

The platform supports several rule‑handling capabilities:

Input data integrity validation (type, length, range constraints).

Inter‑field rule processing (mapping, enrichment, truncation).

Custom scripting for low‑code extensions.

Message header and output field conventions for security tokens, routing, pagination, and error reporting.

Service Composition and Orchestration

Beyond individual APIs, the platform enables service composition and orchestration. Multiple atomic services (e.g., A, B, C) can be combined into a new composite service D, returning aggregated results either in parallel or sequentially. Scenarios include:

Aggregating query results from several services into a single response.

Joining data from separate databases (e.g., material info + purchase order details).

Chaining services where the output of one becomes the input of the next.

Enriching or trimming existing services to create new variants.

These orchestration patterns aim to replace ad‑hoc front‑end composition with visual, reusable workflow definitions.

Source Code Export and Microservice Packaging

For complex business rules that cannot be expressed within the low‑code environment, developers can export the generated source code, which should compile and run independently of the platform. Exported code can be packaged as a JAR for deployment or hosted directly on the platform’s runtime.

Typical service implementation can be wrapped with pre‑ and post‑processing hooks:

//BeforeDo();
//ProcessAPI();
//AfterDo();

Multiple APIs or objects can be bundled into a microservice application, facilitating deployment as a standalone service or within the platform’s microservice runtime.

Conclusion

The article provides a practical roadmap for building a scalable API ecosystem that leverages object‑driven design, automated contract generation, rule processing, visual service orchestration, and seamless transition to microservice deployment, addressing both development efficiency and operational robustness.