The user selects a file and Angular inserts it into a FormData.
Angular · HttpClient · REST API · Frontend integration
Angular communication with a REST API using HttpClient
This article gathers several common patterns that appear when an Angular application consumes an API: GET requests, POST login, JSON response filtering, file download and loading-state handling.
The goal is to keep the interface aligned with the rest of the blog while also leaving reusable examples for future projects where Angular acts as a lightweight client over an independent backend.
What this example covers
The backend exposes several HTTP resources and Angular is responsible for consuming them from a service, processing the responses and correctly reflecting loading, error and result states in the view.
The API base used in the article is: https://servernuevo.1938.com.es/api/v1/
1. Basic GET request
The starting point is a simple call that recovers a greeting from the API. The logic is encapsulated in a service and the component only coordinates state and presentation.
Angular service
This first fragment defines the GET call inside the service. Its responsibility is very concrete: build the request, execute it with HttpClient and propagate any error so the component can react.
The important idea here is to separate HTTP communication from the rest of the application. If the URL, the headers or the error-handling policy change tomorrow, the adjustment is made in the service and not in every visual component.
Example file: `consultarapi.service.ts`
Consumer component
Here the component calls the service, activates the loading state, clears previous results and decides what to do when the API responds correctly or returns an error.
This split of responsibilities is the pattern you will repeat most often in Angular: the service obtains the data, the component decides how to use it and the template only renders the resulting state.
Example file: `saludar-servidor.component.ts`
HTML view
The template connects user interaction with the component method and conditionally shows the result or the spinner. It is the visible part of the flow that we separated in the two previous fragments.
Notice that the view does not contain business logic. It only binds events, shows states and displays the response to the user, which is exactly what we want in a maintainable interface.
Example file: `saludar-servidor.component.html`
GET call demo
This button executes the service and shows the response on screen. The example is useful to review the complete flow of loading, error handling and JSON rendering.
2. POST login
Another classic pattern consists of authenticating the user by sending credentials and recovering a token. In this case the API returns a JSON object with the access information that can later be reused for protected requests.
This block implements the authentication POST request. It builds the payload with username and password, sends it to the corresponding endpoint and types the response so the token can be used later.
Unlike the previous GET example, here the client no longer only reads information: it sends data to the server and waits for a response that conditions access to the rest of the protected resources.
Example file: `consultarapi.service.ts`
User model
This model defines the minimum structure Angular needs to work with the credentials and the token returned by the API.
Keeping this model separate helps maintain a clear contract with the API and avoids treating the response as a generic unstructured object.
In small projects this step is sometimes skipped, but defining the model from the beginning makes the code easier to read and reduces errors when the application starts to grow.
Example file: `user.ts`
Store the token and render the state
Once the user is authenticated, the component stores the token and decides what to show on screen.
This code represents the intermediate step between authenticating and using the protected API: validate the response, store the token and update the visual state of the component.
Even though the example is simple, conceptually this is the point where the frontend moves from being an anonymous client to being an authenticated client capable of accessing more backend functionality.
Example file: `login.component.ts`
3. JSON response filtering
Sometimes the API returns a large structure and the component only needs one part. In that scenario, map makes it possible to expose only the useful fragment of the response.
This JSON simulates a more complex API response. It is not always useful to render the full object: many times only one part contains the information relevant to the interface.
This scenario is very common when working with real APIs, because the response usually includes metadata, pagination, links or internal structures that do not need to be shown directly on screen.
The following service transforms the response and returns only the datos block.
Here map is used to extract that useful part. This simplifies the component because it receives the result already adapted to the use case instead of having to navigate the whole JSON structure manually.
When this kind of transformation is solved in the service, the component stays much cleaner and the pattern becomes reusable if another part of the application needs the same processed information.
Example file: `consultarapi.service.ts`
View prepared to display the JSON
The template of this example keeps the same idea as the GET request: a button to trigger the action and a visual area that shows the returned content or the loading state.
This also reinforces an important idea from the tutorial: even if the type of data or the way it is obtained changes, the visual structure of the component can remain stable and predictable.
Example file: `obtener-json.component.html`
Component logic
In this fragment the component consumes the response already transformed by the service and leaves it ready to be shown on screen with no extra processing.
That makes the component behave almost the same as in the GET example, with the difference that the data now arrives more refined and adapted to the specific problem.
Example file: `obtener-json.component.ts`
4. File upload and download
APIs do not only exchange JSON. In many projects there is also a need to upload documents, process them on the server and return a downloadable blob to the user.
The POST request sends the binary content and waits for another response in blob format.
The frontend generates a temporary link to download the returned PDF.
The component reflects its state to avoid repeated clicks and silent errors.
Upload form
This HTML represents the input side: the user selects a file, the form validates that it exists and everything gets prepared to send it to the backend.
At this stage the goal is not yet to upload anything, but to correctly capture the file and control that the user does not submit the form empty or in an invalid state.
Example file: `cargarfichero.component.html`
Capturing the file
The following method takes the file selected in the input and stores it inside the reactive form, which will be the source of the FormData sent to the API.
This step often creates doubts at the beginning because a file input is not handled like a normal text field. That is why it is worth isolating that logic in a specific method.
Example file: `cargarfichero.component.ts`
POST of the file
Here the request that sends the document to the server is built. The special point is that we are not expecting JSON, but another binary response prepared to be downloaded afterwards by the user.
That difference is key: when working with files, Angular needs you to explicitly indicate the expected response type so it does not try to interpret the content as JSON.
Example file: `consultarapi.service.ts`
Receiving the blob
This block shows how to handle the server response when it arrives as a blob: a temporary URL is generated and the browser download is triggered.
At the end of the day, this is the bridge between the technical backend response and the final user experience, where the user simply expects to receive a downloadable document.
Example file: `cargarfichero.component.ts`
Python endpoint example
To better understand what Angular receives, here you can see the server side: a Python resource that locates a file on disk and returns it as a downloadable HTTP response.
Seeing both sides, backend and frontend, helps explain why the browser receives a blob and what behavior is expected when the endpoint responds correctly.
Example file: `api.py` or equivalent Python resource
Angular service for download
From Angular, the service must indicate headers and responseType correctly so the response is not interpreted as JSON and can be handled as a binary file.
This detail is usually what marks the difference between a download that works and an integration that fails with parsing errors or a corrupted file.
Example file: `consultarapi.service.ts`
Download demo
The reusable component below encapsulates the PDF download logic and lets the main page stay focused on explaining the pattern.
Descarga de PDF desde la API
Ejemplo práctico de respuesta `blob` y descarga del fichero generado por el backend.
Download button view
This template is the reduced version of the download component. Its role is to offer a clear action to the user and visually reflect whether there is loading or whether the response has arrived correctly.
The interesting part of this example is that it shows how to encapsulate a complete behavior inside a small reusable component.
Example file: `descargar-pdf.component.html`
Download component logic
Finally, this block joins all the pieces together: it calls the service, controls the spinner state and triggers the actual PDF download when the backend responds.
If you compare this flow with the previous sections, you will see that the general philosophy does not change: service for communication, component for state and template for presentation.
Example file: `descargar-pdf.component.ts`
5. Main idea
The key to this integration is not only calling the API, but correctly separating the HTTP service, the component state and the visual presentation. That separation makes the code easier to maintain, more reusable and more consistent with the rest of the project.