Principle:OpenHands OpenHands Business Route Mounting
| Knowledge Sources | |
|---|---|
| Domains | Server_Architecture, SaaS_Infrastructure |
| Last Updated | 2026-02-11 21:00 GMT |
Overview
Mounting business logic API routers for billing, organizations, and user management organizes the server's REST endpoints into cohesive domain-specific modules that can be developed and tested independently.
Description
The Business Route Mounting principle governs how domain-specific API endpoints are structured and registered with the application. Unlike integration routers (which are conditionally mounted), business routers represent core SaaS functionality that is always present: billing and subscription management, organization and team administration, API key lifecycle, user feedback collection, email notification preferences, and shared conversation access. Each business domain is encapsulated in its own router module with clearly defined URL prefixes, request/response schemas, and dependency requirements. Mounting these routers during server assembly creates a well-organized API surface where related endpoints share a common URL namespace and middleware configuration.
Usage
Apply this principle when structuring the REST API of a SaaS application that spans multiple business domains. Each domain should own its router, models, and business logic. The mounting phase during server assembly determines the final URL structure and ensures that all domain routers are registered with appropriate prefixes and tags. This pattern enables parallel development across teams, as each domain router can be developed and tested in isolation.
Theoretical Basis
The modular routing pattern organizes REST endpoints by business domain, following the principles of domain-driven design. Each router module represents a bounded context with its own vocabulary, operations, and invariants. By grouping endpoints into domain-specific routers, the application achieves high cohesion (related endpoints are co-located) and low coupling (domains interact through well-defined interfaces rather than shared implementation details). The FastAPI include_router mechanism supports this pattern by allowing each router to define its own prefix, tags, dependencies, and middleware, while the main application composes them into a unified API. This approach scales well as the application grows: new business domains are added as new router modules without modifying existing ones, and the URL namespace naturally reflects the organizational structure of the business logic.