API naming assigns user-visible identifiers to functions, methods, resources, fields, and other API elements. Good names are simple, expressive, and predictable; poor choices can impose compatibility costs long after release. section 3.0 section 3.1
Choose names that communicate intent and remain consistent:
- Prefer simple, expressive, predictable terms over clever or ambiguous wording. section 3.2 section 3.8
- Pick a language, grammar, and syntax convention, then apply it consistently across the API. section 3.8
- Treat context as part of meaning, but check that surrounding context does not mislead users. section 3.8
- Include units for primitive values and use richer data types when a name cannot convey enough information. section 3.8
- Avoid prepositions such as “with” and “for” when they signal an underlying design problem or parameterize a standard operation. section 3.8 section 9.3
Naming a custom method
A rocket-launching action can use a resource path such as POST /rockets/1234567:launch, keeping the resource and custom action unambiguous. Name the RPC action with a verb followed by a noun, such as LaunchRocket or ArchiveDocument; avoid names such as CreateRocketForMars. section 9.3 section 9.3
Use the request-component figure to inspect how a custom action fits after the resource path. section 9.3
