<p>I'd make the invocation safe, use some try/catch on the invocation itself. That way, if the API is unreachable or HTTP error code is returned - the app can handle it and present the &quot;error&quot; to the user in a more UX-y way ;)</p>
<p>Second thing, I'd make a returned data validator of some sort. For example data types, structure etc. Especially on key fields. That way we know that nothing that comes from the vendor API is breaking our app and make sure that no data returned won't crash the app on our side.</p>

CC BY-SA 4.0
2021-06-10T12:40:37.153Z
2021-06-10T12:40:37.153Z
Karolina Ochlik
<p>We have an IIS 10 (Windows Server) on-prem application that is calling a cloud vendor api and for some reason the api is not reliable. Sometimes the application returns results as expected. Sometimes no data is able to be retrieved.</p>
<p>We checked our code and suspect it's something on the vendor side and the vendor said they are looking into it.</p>
<p>What ways can we mitigate the issue on our side to improve the quality of the call and improve the experience for the end users?</p>

<windows><servers><api>
How to mitigate issues in an IIS on-prem application calling an unreliable cloud vendor API?
Pie
# How to mitigate issues in an IIS on-prem application calling an unreliable cloud vendor API?

(Asked by: username_0 on 2021-06-10)

We have an IIS 10 (Windows Server) on-prem application that is calling a cloud vendor api and for some reason the api is not reliable. Sometimes the application returns results as expected. Sometimes no data is able to be retrieved.

We checked our code and suspect it's something on the vendor side and the vendor said they are looking into it.

What ways can we mitigate the issue on our side to improve the quality of the call and improve the experience for the end users?

**Tags:** windows, servers, api


---

## 1 answers

### Answer by username_1 on 2021-06-10. Score: 1

I'd make the invocation safe, use some try/catch on the invocation itself. That way, if the API is unreachable or HTTP error code is returned - the app can handle it and present the "error" to the user in a more UX-y way ;)

Second thing, I'd make a returned data validator of some sort. For example data types, structure etc. Especially on key fields. That way we know that nothing that comes from the vendor API is breaking our app and make sure that no data returned won't crash the app on our side.


---

