Use capability resources; functions require the capability as an argument, ensuring only authorized accounts can execute privileged actions.

When you use meaningful resource URIs, implement HATEOAS, and follow HTTP status codes semantically RESTful will definitely turn out the best API for use.

Move handles access control through capabilities, which are first-class resources representing authority over specific actions or objects. Unlike Solidity’s onlyOwner modifier, which relies on runtime checks against a single owner address, Move enforces permissions at the type level: functions requiring sensitive operations must receive the appropriate capability as an argument, and only accounts or modules holding that capability can invoke them. This enables fine-grained, composable, and transferable permissions, supports delegation or revocation, and guarantees at compile time that unauthorized operations are impossible. By leveraging the type system and resource semantics, Move provides a more secure and flexible alternative to owner-based access control patterns.

You handle access control in Move through a capability-based system instead of global checks like Solidity’s onlyOwner. In Move, special objects called capabilities (for example, MintCap or BurnCap) are created and given only to authorized accounts, and whoever holds that capability can perform the restricted action. This means you don’t rely on a single hardcoded address but on possession of a unique resource object that can be transferred, revoked, or stored safely. Because capabilities follow Move’s strict ownership rules, no one can copy or fake them, which makes access control both flexible and secure.