An API name identifies its subject matter, business concept, use case, or offered capabilities. A clear name sets boundaries and helps potential consumers find and understand the API. section 11.3 section 11.0
Choose a name that remains meaningful beyond its original project context:
- Focus on the domain, business concept, use case, or actual capabilities rather than a generic label. section 11.3.2
- Avoid names such as “API” or “Web Service,” which cannot distinguish one API from another. section 11.3.2
- Avoid project or context names such as “New Banking Architecture,” because the project may end while the API remains. section 11.3.2
- Use plain names such as “Banking,” “Account,” or “Money Transfer,” optionally adding the “API” suffix. section 11.3.2
- Name the actual offered capabilities: a “Banking” API limited to account information may mislead consumers. section 11.3.2
Comparing API names
“API” and “Web Service” reveal nothing about purpose. “New Banking Architecture” describes an internal project, while “Banking” may overstate capabilities. “Account” better communicates an API focused on account information. “Online Money Transfer” is meaningful but may unnecessarily limit an API also intended for mobile and batch consumers. section 11.3.2
Treat the name as provisional during design. Base the initial choice on expressed user needs, then finalize it after deciding API granularity and developing the detailed API set. section 11.3.1 section 11.3
