mirror of https://github.com/furyhawk/api_gateway.git synced 2026-07-21 02:06:50 +00:00

Files

T

furyhawk 1528a7c769 Add initial implementation of OpenAPI API Gateway framework

- Create core application structure with FastAPI
- Implement dynamic route registration and management endpoints
- Define configuration models for gateway settings, upstreams, and routes
- Add proxy request handling for upstream services
- Include example configuration and OpenAPI specification files
- Set up development dependencies and project metadata

2026-05-31 11:47:08 +08:00

2.4 KiB

Raw Blame History

AGENTS.md

Instructions for AI coding agents in this workspace.

Project Snapshot

Primary artifact: openapi_json/lta_datamall_openapi_v0-1-1.json
Repository scope today: OpenAPI specification only (no server implementation files, tests, CI, or package manager config in repo)
Domain: LTA DataMall bus APIs exposed via a versioned API gateway

Source of Truth

Treat openapi_json/lta_datamall_openapi_v0-1-1.json as the canonical contract.
Do not infer runtime behavior beyond what is explicitly defined in the spec.
Link to existing spec sections instead of duplicating large API descriptions in new docs.

Working Rules

Keep JSON valid and consistently formatted with 2-space indentation.
Preserve existing naming patterns unless asked to refactor:
- Path versioning style: /api/v1/...
- Health probes: /healthz, /readyz
- FastAPI-style operationId names
- Existing query parameter names, including $skip
Prefer additive, backward-compatible API changes for scalability:
- Add new optional parameters instead of changing required ones.
- Add new endpoints or response fields rather than removing/changing existing ones.
For configurability, make behavior explicit in schema/parameters:
- Define parameter constraints (minLength, maxLength, minimum, enums, nullable) where known.
- Document defaults and optionality in schema metadata when adding fields.

Contract Quality Expectations

When editing or adding endpoints, prioritize these improvements:

Reuse components/schemas for shared response/request shapes.
Avoid unbounded additionalProperties: true on new models unless truly required.
Include non-2xx responses (especially validation/auth/upstream failure) when behavior is known.
Keep tag groupings coherent (Health, Bus, etc.) and summaries concise.

Validation Checklist

Run these checks after spec edits (ad hoc, since no build system is committed):

JSON validity check:
- python -m json.tool openapi_json/lta_datamall_openapi_v0-1-1.json >/dev/null
Optional structural check (if available locally):
- npx @redocly/cli lint openapi_json/lta_datamall_openapi_v0-1-1.json

Out of Scope By Default

Do not scaffold app/server code, infra, or deployment manifests unless explicitly requested.
Do not rename existing public endpoints/parameters in place unless explicitly requested.

Key File

openapi_json/lta_datamall_openapi_v0-1-1.json

2.4 KiB Raw Blame History