Question 1

How do you structure the networking layer in Flutter?

Accepted Answer

In layers: an ApiClient (sends requests, applies timeouts, maps status codes) → a repository (returns domain objects, decides on caching) → the UI. Widgets never call HTTP directly. The concrete details: an explicit timeout on every request; status codes mapped to domain failures (401 → UnauthorizedFailure); the token attached centrally by an interceptor. Justify the package choice: dio when you need interceptors and cancellation, the official http for simple cases. Finish with testing — with ApiClient behind an interface the repository is testable without a network.

Question 2

What should happen on a 401 response?

Accepted Answer

The sequence: the interceptor catches the 401, obtains a new access token with the refresh token, and retries the original request with it, invisibly to the user. If the refresh itself fails (the refresh token has also expired), the user is signed out and sent to login. The important technical detail: when parallel requests hit 401 at the same moment the refresh must run once — I hold the in-flight refresh future and let the others await it. Otherwise five refreshes fire, and on some backends that invalidates the previous refresh token and logs the user out.

Question 3

When is it safe to retry a request?

Accepted Answer

The criterion is idempotency: if executing the request twice does not change the outcome, retrying is safe. GET, PUT and DELETE usually are; POST is not. The classic hazard: the POST reached the server and created the order, but the response was lost in transit — a blind retry creates a duplicate. The mitigations: retry only on connection-level failures where the request never landed, use an idempotency key for POSTs so the server recognises the repeat, and apply exponential backoff so you do not worsen an already-struggling server.

Question 4

How do you choose between http and dio?

Accepted Answer

By need, not by fashion. http is the Dart team's official package, small, and entirely sufficient for a handful of simple requests — avoiding an extra dependency has value in itself. I move to dio when I need interceptors (tokens, logging, central error handling), request cancellation, form data or file uploads, or want to centralise timeout and retry policy. A practical note: those needs almost always appear as a project grows, so starting with dio on mid-sized and large projects usually pays off — but it should be argued as a decision rather than assumed.

Networking: http and dio

📚 Sources and documentation