The heart of any Rosetta API implementation is populating transaction operations. Most work of mapping network-specific abstractions to Rosetta abstractions occurs here. Depending on the type of operation, there are different expectations around an implementation's support.
To be considered a "complete" implementation, the balance computed from all
of an account's operations must equal the balance returned for an account
/account/balance endpoint at the end of each block. If these balances
do not match (often referred to as reconciliation) for any account, some clients
will not be able to integrate with the blockchain you are working on.
In blockchains with generic smart contracting, detailed parsing of operations can require contract-specific parsing logic. There is no expectation that a Rosetta Data API implementation can parse all deployed contracts with detail but it is expected that any balance changes that result from contract execution are represented (often referred to as tracing).
Frequently, blockchains have non-balance-changing operations (i.e. voting for a governance proposal or nominating validators in a PoS network). While there is no specific expectation for supporting operations that do not change balance, implementers are encouraged to include as many operations as possible in a Data API implementation as many developers will rely exclusively on your implementation to interact with the blockchain you are working on. If useful operations are not supported, they will not be able to perform those operations on the blockchain you are working on.