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
Trace the sequence from creating a draft through SMTP delivery to the final sent state. section 9.3.1























