liveBook · Manning

Indicative mood

As explained in API Design Patterns

The indicative mood expresses a statement or question about a state or condition rather than a command.

The indicative mood expresses a statement or question rather than a command. In API names, it often describes an investigation, such as whether a value is valid, instead of directing a service to change something. section 3.3.2

Imperative REST verbs make commands explicit: CreateBook, DeleteWeatherReading, and ArchiveLogEntry. Indicative names can obscure whether an operation runs locally or makes a remote call, especially when they resemble ordinary predicates. section 3.3.2

Validation response shape

An RPC named isValid() leaves the response unclear: it might return a Boolean or validation errors. GetValidationErrors() communicates a more predictable contract, returning an empty list for valid input or a list of errors otherwise. section 3.3.2

When naming indicative API operations:

  • Prefer names that reveal whether the operation retrieves information or performs a command. section 3.3.2
  • Make the expected response explicit instead of hiding its shape behind a yes-or-no predicate. section 3.3.2

How API Design Patterns covers it

How deep it goes
Contrasts indicative and imperative naming through API examples and response-shape consequences.
Examples
Uses String.IsNullOrEmpty(), isValid(), GetValidationErrors(), CreateBook, DeleteWeatherReading, and ArchiveLogEntry.
What you can do after
Evaluate API operation names for remote-call ambiguity and choose response shapes that communicate their contracts.
How it connects
Connects indicative mood with imperative mood, REST, RPC, remote calls, and response design.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of API Design Patterns. The section links point to the parts of the book it draws on.