The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Sending an HTTP request to an external service takes a few lines of code. The harder work starts when your application has to decide what the response means, and how it should behave when the service is slow, inconsistent, or unavailable. Devanshu Patil’s DEV Community article with this title frames the core question well: How does my application safely depend on a system I don’t control?
A successful response does not tell you what the data means
An HTTP 200 with an empty list is a successful response, but it can mean three different things. It may be a genuine empty result. It may be a query that filtered out everything because a parameter was wrong. It may also be a temporary problem on the provider’s side that returned incomplete data. The status code cannot tell these apart, so your application needs context to decide.
As an Amazon Associate I earn from qualifying purchases.
Useful questions to ask of a valid-looking response include:
- Should this query normally return results for these inputs?
- Does the provider’s documentation say an empty set is a meaningful answer?
- Have recent calls with similar inputs returned data?
Patil uses the empty list as an example, not as a universal rule. The same reasoning applies to any response whose body is well-formed but whose business meaning is uncertain.
#1 Best Overall
Treat the external API as a boundary
A provider’s payload carries its own naming, nesting, and assumptions. If handlers across your codebase read those fields directly, every module inherits the provider’s design, and a rename on their side becomes a change across your application. The safer pattern is to keep the external format at the edge of your system:
- Make the raw HTTP call and parse the response in one client module.
- Validate required fields and their types before anything else reads them.
- Map the validated data into your own internal types, using your own names.
- When validation fails, report it as a provider contract problem, not as a null-reference error in unrelated code.
Status codes as part of the contract
Treat status codes as information, not as a simple success-or-failure switch. RFC 9110, HTTP Semantics, published by the Internet Engineering Task Force in June 2022 as a standards-track document, defines what the codes mean at the protocol level. It describes HTTP as “a stateless application-level protocol for distributed, collaborative, hypertext information systems.” At the class level, 4xx responses indicate that the client seems to have erred, and 5xx responses indicate that the server knows it has erred or cannot perform the request.
Rank #2
- Used Book in Good Condition
The specific codes carry more precise meanings than their class:
Recommended Free Tools
| Status | Meaning under RFC 9110 | What your client should infer | Repeating the same request |
|---|---|---|---|
| 401 | The request was not applied because valid authentication credentials are missing. The response must include a WWW-Authenticate challenge. | The credentials for this request are missing or rejected. | Will not help until the credentials change. |
| 403 | The server understood the request but refuses to fulfil it. | The caller lacks permission for this action, even if authenticated. | Will not help unless permissions change. |
| 404 | The origin server has no current representation for the target resource, or is unwilling to disclose one. | The resource is not available to you now. It may never have existed, or it may have been removed or hidden. | Only useful if the lookup key may have been stale. |
| 503 | Temporary overload or maintenance. May include Retry-After. | Transient unavailability. | May succeed after the indicated delay. |
| 504 | A gateway or proxy did not receive a timely response from the upstream server. | The upstream outcome is unknown, not necessarily failed. | Depends on whether the operation is safe to repeat (see below). |
The shorthand “401 means log in again” or “404 means it never existed” is too coarse. A 401 concerns credentials on the request, and a 404 describes what the server is currently willing to represent. Keeping these definitions intact lets your application choose a different action for each case instead of flattening all of them into “something went wrong.” A 5xx is not an automatic retry signal, though. Whether to repeat a request depends on the operation and on your application’s policy.
Retries and the response that never arrived
A retry can cause harm when the original operation completed but the client never received the response. Consider a transaction endpoint. The client sends a request, the server records the transaction, and the connection drops before the response arrives. The client sees a timeout and sends the same request again. If the endpoint has no deduplication, the second request creates a second transaction. This is an illustrative scenario from the article, and it does not mean every POST creates duplicates. It shows why retry behaviour must depend on what the operation does.
RFC 9110 defines idempotent methods by their intended effect: multiple identical requests should have the same effect on the server as a single one. A request with idempotent semantics can be repeated after a communication failure. A request without them needs an explicit strategy, such as a client-generated key that the provider can use to recognise a repeated attempt, if the provider supports one.
The questions to answer before adding a retry
- Does the operation change state on the provider’s side?
- Are repeated identical requests safe under the provider’s documented behaviour? If not, is there a deduplication mechanism?
- Is the failure transient, such as a timeout or a 503, or does it need a corrected request, as with most 4xx responses?
- What will the user see while the call is retried: a spinner, a cached value, or an error?
Timeouts give failure a bounded shape
Without a timeout, a stalled call can hold connections and threads indefinitely. Set one on every outbound call. The article recommends timeouts but does not establish a universal numeric value, and this guide does not supply one. Choose the value from the provider’s observed latency and from how long your users will realistically wait, and measure both in your own environment.
A timeout should also be treated as an unknown outcome, not a confirmed failure. That is the same lesson as the lost response above: the provider may have finished the work after your client stopped waiting.
Best Value
Keep integration logic out of your core
The external-service concerns described above should live in a small set of places:
- A client module that owns the HTTP call, authentication, and timeouts.
- A mapping layer that turns provider payloads into internal types and rejects malformed data.
- A retry policy that knows which operations are safe to repeat.
- Domain code that works only with internal types and never sees provider field names.
With this separation, a provider change affects the client and mapping modules, and tests for domain code can substitute a fake client.
Where the standard stops and your design begins
RFC 9110 defines protocol semantics: what a method means, what a status class signals, and when a request is idempotent. It does not define the business rules a particular API adds on top, such as which fields are required, which empty results are meaningful, or whether a given operation supports deduplication. Those rules come from the provider’s documentation and from your own decisions about user experience. Patil’s guidance is engineering advice built on the protocol definitions, and it is most useful when you apply it to the specific APIs your application depends on.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Further reading
For broader coverage of API design, John J. Geewax’s API Design Patterns is a 480-page book published in July 2021 that covers design principles, patterns, and edge cases. It is useful background for designing APIs of your own, but it is not required for understanding the points above.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
