liveBook · Manning

Side effect

As explained in API Design Patterns

A side effect is an observable state change or additional operation caused by an action beyond its primary specified result.

A side effect is an additional observable operation or state change beyond an API method’s primary specified result. Predictable standard methods avoid unexpected behavior, while custom methods provide an explicit home for consequential actions. section 7.3.2 section 9.3.1

Use these distinctions when designing or evaluating API methods:

  • Keep standard methods limited to their stated resource operation; do not attach unrelated actions such as sending email, triggering background work, or updating other resources. section 7.3.2 section 9.3.1
  • Separate consequential workflows into custom methods whose names and behavior make the additional operation explicit. section 9.3.1
  • Check side effects alongside idempotence: hidden state changes can make repeated requests behave differently, risking data loss or corruption. section 7.3.2 section 7.6
  • Treat validation requests as completely safe and repeatable: they must change no data and produce no side effects. section 27.3

Separating email creation from sending

CreateEmail should store an email as a draft and do nothing else. A custom SendEmail method can contact SMTP servers and transition the email to sent only after delivery succeeds. This keeps storage separate from the external operation and its failure modes. section 9.3.1

Figure 9.3 Sequence diagram demonstrating sending an email using custom methods

Trace the sequence from creating a draft through SMTP delivery to the final sent state. section 9.3.1

How API Design Patterns covers it

How deep it goes
Defines side effects, tests them against idempotence, and applies the distinction to email workflows and validation requests.
Examples
Uses email storage versus SMTP delivery, retrieval counters, background operations, resource updates, and validate-only requests.
What it assumes
Assumes familiarity with API methods and resources while defining side effects, idempotence, and validation behavior through concrete scenarios.
What you can do after
Designs API workflows that keep standard methods predictable and move additional operations into explicit custom methods.
How it connects
Connects side effects to standard methods, custom methods, idempotence, resource operations, and request validation.

Also explained in

Compare how 24 books explain side effect →

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.