Fetch API: sending a request and checking the response

Useful to know

Fetch API gives JavaScript an interface for sending HTTP requests and processing responses. Typically, the fetch function receives an address and optional request settings. It returns Promise, which when executed provides object Response. The program can then look at the status, headers, and content. This sequence separates several tasks that, when reading a short example, are easily perceived as one action: sending, receiving, evaluating, and using the data. [1]

Especially important is the difference between network failure and HTTP response with error status. Fetch does not reject Promise only because the server has responded with 404. Therefore, the code must check the resulting status. [1] The Response.ok property is a Boolean value that indicates whether the status is in the 200 to 299 range. [2] Thus, the application has a convenient first check, but still has to determine what a successful answer means for its own task.

Let's look at a fictional catalog that loads data for a selected book. For it, we can describe at least four different situations: the book is found, the address returns a missing resource, the exchange does not end, and the content does not have the expected fields. The visitor is not interested in the names of the objects in the program, but he needs to find out which result has occurred. That's why the general "something went wrong" message is not a good enough behavior specification.

Reading the body is also a separate asynchronous step. The json method provides processing as JSON, and text allows reading as text. [1] The selection must correspond to the contract with the service. If the app expects a list of books, the practical check can describe which fields it uses and how it reacts when they are missing. Thus, obtaining syntactically valid content is not mixed with confirmation that the data is suitable for display.

For a learning test, it is useful to replace the address with controlled examples that return different answers. For each example, we record the expected caption, the status of the button, and the content of the resulting list. It is not necessary to send real changes to someone else's service to check the interface. The well-described scenario allows to see if the program correctly distinguishes receiving a response, successful status and appropriate data.

Upon completion of the function, it is useful to check that all selected paths end understandably. The loading indicator should have a described end, and the retry should start from a known state. This turns a short network operation into a complete user function. Fetch provides the exchange mechanism, but clear behavior comes from individual checks and from the pre-defined meaning of each possible result for the specific page. In the catalog, the check must distinguish a missing book from a failed reading of the answer received.