Imagine a player pressing Buy in an in-game shop. The interface can explain the item and display progress. The request arriving at the server is still untrusted input. Showing a button does not prove that a player is allowed to receive its reward.
Send the intent
A request can identify the item the player wants. The server should look up its own item definition and price instead of accepting a price or reward amount supplied by the client. The interface is a way to request an action, not the authority that grants it.
Check the whole request
Validate the input type and allowed value, then check context: does the item exist, can this player buy it here, and do they meet its requirements? Include limits on request frequency. A valid-looking item identifier alone does not establish permission to complete the purchase.
Plan repeated and failed actions
A player can click twice, disconnect or receive a delayed response. Define what happens to currency, ownership and feedback in each case before building the happy path. Keep authoritative state changes on the server and test how your design avoids granting the same result more than intended.
Keep the interface clear
The client should show a useful response: success, insufficient currency or a temporary inability to complete the action. Do not expose sensitive internal state in errors. This small example is a way to reason about boundaries, not a complete secure shop implementation or a substitute for a project-specific security review.
Further reading
These are original learning notes. Check the current official documentation when implementing platform features.