AIP-140

Field names

Naming fields in a way that is intuitive to users can often be one of the most challenging aspects of designing an API. This is true for many reasons; often a field name that seems entirely intuitive to the author can baffle a reader.

Additionally, users rarely use only one API; they use many APIs together. As a result, a single company using the same name to mean different things (or different names to mean the same thing) can often cause unnecessary confusion, because users can no longer take what they’ve already learned from one API and apply that to another.

In short, APIs are easiest to understand when field names are simple, intuitive, and consistent with one another.

Guidance

Field names should be in correct American English.

Field definitions in protobuf files must use snake_case names. These names are mapped to an appropriate naming convention in JSON and in generated code.

Field names should clearly and precisely communicate the concept being presented and avoid overly general names that are ambiguous. That said, field names should avoid including unnecessary words. In particular, avoid including adjectives that always apply and add little cognitive value. For example, a proxy_settings field might be as helpful as shared_proxy_settings if there is no unshared variant.

Consistency

APIs should endeavor to use the same name for the same concept and different names for different concepts wherever possible. This includes names across multiple APIs, in particular if those APIs are likely to be used together.

Repeated fields

Repeated fields must use the proper plural form, such as books or authors. On the other hand, non-repeated fields should use the singular form such as book or author. This implies that resource names should use the singular form as well, since the field name should follow the resource name (e.g., use repeated Book books, not Books books = 1).

Prepositions

Field names should not include prepositions (such as “with”, “for”, “at”, “by”, etc). For example:

  • error_reason (not reason_for_error)
  • author (not written_by)

It is easier for field names to match more often when following this convention. Additionally, prepositions in field names may also indicate a design concern, such as an overly-restrictive field or a sub-optimal data type. This is particularly true regarding “with”: a field named book_with_publisher likely indicates that the book resource may be improperly structured and worth redesigning.

Note: The word “per” is an exception to this rule, particularly in two cases. Often “per” is part of a unit (e.g. “miles per hour”), in which case the preposition must be present to accurately convey the unit. Additionally, “per” is often appropriate in reporting scenarios (e.g. “nodes per instance” or “failures per hour”).

Adjectives

For consistency, field names that contain both a noun and an adjective should place the adjective before the noun. For example:

  • collected_items (not items_collected)
  • imported_objects (not objects_imported)

Booleans

Boolean fields should omit the prefix “is”. For example:

  • disabled (not is_disabled)
  • required (not is_required)

Note: Field names that would otherwise be reserved words are an exception to this rule. For example, is_new (not new).

Reserved words

Field names should avoid using names that are likely to conflict with keywords in common programming languages, such as new, class, function, import, etc. Reserved keywords can cause hardship for developers using the API in that language.

Further reading

  • For naming resource fields, see AIP-122.
  • For naming fields representing quantities, see AIP-141.
  • For naming fields representing time, see AIP-142.