Mobile API contracts: what to check after HTTP succeeds

An HTTP 200 can contain an HTML page

A mobile client can receive a proxy error page, a login page or a response from the wrong endpoint. A platform success callback means a response arrived; it does not mean response.data follows the application contract.

The current api adapter rejects null, strings, arrays and ArrayBuffer before checking for HTTP 2xx and code === 0. Rejection gives the page a chance to leave its loading state and display an error.

This checks only the response envelope. The api<T> generic does not prove at runtime that data.data satisfies T; amounts, permission fields and dates still need explicit validation.

A stale request must not sign out a new session

Consider this sequence: account A sends a request, the user switches to B, and A’s 401 arrives later. Clearing storage on every 401 would sign B out too.

The adapter captures requestToken at dispatch. It clears the session and emits session-expired only when that token is nonempty and still equals the current token. Uploads and downloads need the same ownership check.

// Excerpt of the session ownership rule
const requestToken = getToken();
// ...dispatch with requestToken...
if (response.statusCode === 401 &&
    requestToken && requestToken === getToken()) {
  setToken('');
  uni.$emit('session-expired');
}

Network failure and session expiry need different actions

An ordinary network failure should preserve the token. A short loss of connectivity should not force a new login. Requests currently use a 20-second timeout and transfers use 60 seconds; these are waiting limits, not performance targets.

A shared error message is not a complete recovery strategy. Reading a list can be retried, but orders or messages require checking whether the server already processed the write. A missing response does not prove nothing happened.

Test the order of failures

• Existing fixtures reject empty, HTML and malformed responses, and preserve the token on network failure.
• Existing fixtures clear the current session on its own 401 while protecting a new token from an old response.
• Proposed checks include missing or mistyped data.data fields, stale responses after signing in again, and different retry policies for reads and writes.

The 31 published mobile logic checks use mocked uni APIs and conditional-compilation preprocessing. They test response handling, not real WeChat containers, system keyboards, cameras or GPS.