On mobile products the network can drop, the app can stay on an old version, and the user can send the same request twice. Designing an API only for ideal conditions leads to unexpected errors in the field.
First six decisions
- How will API version migration happen?
- When a request repeats, will the action be created twice?
- What will the user see on a slow network?
- How will token refresh and device revocation work?
- Is the response structure consistent in error cases too?
- How long will sensitive data stay on the device?
Idempotency is a real product feature
When a payment or order request repeats because of the network, the server must recognise the same operation ID and not create a second order. This decision stretches from user experience directly to financial trust.
Do not punish the old client
Mobile users may not install an update immediately. The API needs backward compatibility, an open deprecation calendar and a safe shutdown plan.
Source / further readingOWASP — API Security ProjectThis article does not copy the original content of the source; it is WYN’s practical interpretation. For current headlines, check the publication date and the source page separately.