How JARVIS Enables Seamless API Mocking and Resource Isolation for Large‑Scale Travel Services

Part 1 Background

Large transportation services need to integrate external suppliers for tickets, trains, car rentals, and airport transfers, most of which expose HTTP/HTTPS APIs. To keep development on schedule and support multi‑scenario testing, the team required a way to mock these supplier interfaces. Previously, calls to external APIs were unmanaged, lacking toggles, statistics, and limits.

Part 2 Design Principles

Graphical operation with a management console that is friendly to developers and testers.

Non‑intrusive to business code; test and production code remain identical.

Business relevance by linking configurations to business lines, environments, and suppliers.

Rich matching rules covering most use cases.

Configuration‑as‑code: rule changes take effect immediately.

Traceable request/response with detailed logging and query capabilities.

Part 3 Design and Implementation

The supplier resource control system sits between the internal gateway and external supplier APIs, acting as a global proxy for development and testing environments.

The system is divided into two main components:

Config Center: Manages configurations for business lines, environments, suppliers, supplier APIs, and mock rules.

API Server: Handles request reception, mock rule matching, response generation, and logging.

Key Functions

Separated Config Center and API Server supporting clustered deployment.

Both mock response and proxy access modes.

Hot‑reload of mock rules upon modification.

Automatic adaptation to upstream environment isolation.

Multiple scenarios per API with priority handling.

Mock rules linked to business entities (line, environment, supplier, API).

Request count tracking with overload circuit‑break and alerting.

Comprehensive request/response logging and visual query via Elasticsearch.

Rule Configuration and Management

Configurations include business line info, environment settings, supplier definitions, supplier API definitions, and mock rules. Business line examples: domestic tickets, international tickets, train tickets, car rentals, airport transfers.

Environments have two meanings: deployment clusters (dev, qa, sim, prod) and logical isolation tags (e.g., kfpt, cjr) used in QA.

Suppliers are merchants belonging to a business line, and supplier APIs are the HTTP/HTTPS interfaces they expose.

Mock rules simulate or proxy supplier APIs and are scoped to a specific environment and supplier API.

Scenarios differentiate concrete cases (e.g., Beijing‑Shanghai query with specific passenger counts) from generic cases; matching prefers concrete scenarios.

Response Rule Matching and Process

The matching flow is:

Load and refresh rules into cache when empty.

Adapt environment isolation tag (envTag) from HTTP headers.

Match request URL against rules, separating concrete and generic scenario rules; evaluate parameters for concrete rules first.

If a rule matches, determine its type (Mock or Proxy). Mock returns configured status and body; Proxy forwards to the real supplier, then returns the supplier’s response.

Count daily request volume; trigger alerts and circuit‑break if thresholds are exceeded.

Major Features

Multiple Matching Conditions : Supports header, query param, JsonPath, and body extraction.

Hot‑Effective Mock Rules : Rule changes broadcast via RocketMQ; API Server listens and refreshes cache instantly.

Environment Isolation : envTag passed in HTTP headers; URL placeholders {env} are replaced with the actual tag.

Multi‑Scenario Support : Each rule ties to an environment and supplier API, with distinct success/failure scenarios to avoid conflicts among developers.

Over‑limit Circuit‑Break and Alerts : Enforces supplier‑defined request limits; excess triggers degradation and WeChat alerts.

Automatic Message Encryption/Decryption : Handles encrypted supplier payloads, storing plaintext only in the editor and encrypting on save.

Request Logging and Query : Stores request/response payloads, matched rules, etc., in Elasticsearch for analysis.

Part 4 Project Practice

All supplier interfaces have been proxied in development and testing environments.

Domestic Open Platform Support : Generated full mock data for incomplete supplier interfaces, creating scenario‑specific mock rules to keep development on track.

Summer Stress Test Support : Used mock functionality to isolate external suppliers and simulate varied response times.

Part 5 Roadmap

Supplier Interface Management: Define and manage API schemas, validate request parameters and responses.

Template‑Based Responses: Reduce manual configuration and improve efficiency.

Enhanced Statistics System: Visualize resource usage.

Usability Improvements: Collect feedback to make the system more usable, reliable, and user‑friendly.

Conclusion

The JARVIS system now powers international and domestic ticketing, airport transfer, and other travel services, having undergone multiple large‑scale project validations with ongoing performance and availability optimizations.