A specific operation serves a particular use-case step or context instead of aiming for broad reuse. It can make a flow clearer and reduce consumer processing, but turning every step into an operation creates duplication and weak reuse. section 2.5.1 section 10.1.4
Choose a specific operation when:
- A generic operation would require consumers to filter, combine, or interpret data before continuing the flow. section 10.2.2 section 10.3.5
- The required data would push an existing operation beyond its subject-matter scope. section 10.3.5
- An aggregation represents a meaningful domain concept rather than a consumer-specific convenience. section 10.3.6
- Keep the operation understandable and interoperable; excessive aggregation can obscure data meaning and operation granularity. section 10.3.6 section 10.5
Money-transfer eligibility
Instead of adding transfer-specific parameters to GET /accounts, expose GET /transfer-sources to return accounts eligible as transfer sources. Then expose GET /transfer-sources/{accountId}/destinations to combine eligible accounts and beneficiaries for that source. These operations prevent guesswork and intermediate data processing without requiring a separate resource representation for every source. section 10.3.5 section 10.3.6
Figure 10.6 The “List transfer sources” operation prevents adding money transfer parameters to “List accounts.” The “List destinations for source” use-case-specific operation avoids processing data of the generic “List accounts” and “List beneficiaries” operations.
Compare generic account and beneficiary operations with transfer-specific source and destination operations, including how source eligibility shapes the destination list. section 10.3.5 section 10.3.6
