I'm developing a service that communicates with an external API, but I have a problem
Specifically,
The json schema of the external API response is designed to assume that the correct one will come as per the document.
Recently, due to a system problem with an external API, when a response body is not present, a large number of abnormal terminations occurred due to a nil error.
When I looked at the source code, I found that there was a response body and that the json in the response body had properties (the schema of json is correct).
Therefore, if the response body does not exist due to external API system problems, or if the response json format is different (although this has never actually happened), the response will end abnormally due to a nil error.
So I thought about it
I thought I should put in a mechanism to check the schema of the response json correctly.
If the response json has a different schema, raise a special exception to stop the processing, rescue it at the caller, and handle it so that it ends in the appropriate way.
I have a question for those who create services that work with external APIs.
Have you checked the schema of the external API response?
Or do you write the code so that no errors occur even if the schema is not correct?
Or do you assume that you trust the external API and only get the correct schema response?
Whether or not to check the schema of external data depends on the requirements and budget.
First of all, the more you check, the higher the cost.
It's natural to check the properties of objects every time and handle exceptions properly, but when you design a test, you have more conditions and more verification man-hours.
For example, if it is a very fatal process and it stops due to an error, if it affects overall sales, service, or human life, it will definitely be checked strictly.Don't want to make a single drop of errors If you don't want to stop the service, spend your budget describing the error handling.
However, most of the services in the market do not require such strictness.
In that case, it is important to verify your responsibilities.
It depends on the specifications of the external API, but it is necessary to properly hear what they may return.Is there a possibility that the sky will return?Is it possible to return non-JSON text?Will the response header definitely return the correct one?
Let's check this area first.
Therefore, if JSON's schema changes or fails to return JSON, it is the responsibility of the external API, so it is important to avoid it with the terms and conditions of your product.
However, in the case of APIs, there is a good chance that the other service will fail to get out of the network due to problems with your network.
So we're going to spend
on the risk of our own network failure.
Is the response header retrieved correctly?Check that the returned item exists and is JSON.It can also be handled with more serviceability (error detection and notification, and service reversion).Risk management is essential as this is a category of responsibility for our services.
As is the case with everything, it is necessary to determine the extent to which the project can be costed against any risk, and to manage and develop it properly by project product.
© 2024 OneMinuteCode. All rights reserved.