If you're building a website, you'll probably want to stick to Javascript over Rust.

This MDN article does a pretty good job at introducing the concept of making network requests in Javascript: https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Scripting/Network_requests. It focuses on the "fetch" API as the tool for making requests, which is the standard way to make network requests in Javascript. There are other tools like Axios that may make things easier, but "fetch" should be fine for your use case.

Another concept that will be relevant here is asynchronous programming: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Async_JS/Introducing. Basically, there will be some delay between when you make the request and when you get a response. So you'll need to write your logic in a way that does the "waiting" part correctly.

One important detail is that most APIs use some form of authentication. So when you're "grabbing the data" from an external site, the site knows who you are and that you are allowed to access that data. Getting authentication right might be a little tricky, but here is an entry point: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication. Basically, you'll need to figure out what authentication strategy your headless CMS is using, and then make sure to safely pass those credentials when making your network requests. If the API(s) you are using are public, you won't need to worry about this.

If your goal is primarily to get data from an external source, this should be a good starting point. You don't necessarily need to get too deep into the backend or even the technical details of things like HTTP or REST. However, if you're interesting in getting a deeper understanding of Web APIs, the other comment talking about building a skeleton API would be a good exercise.

In that case, my suggestion would be to target implementing a REST API with OpenAPI (formerly Swagger). There are server code generators for both Rust and JS (multiple flavors, I think).

Basically, the workflow is something like this:

1. Create your API spec skeleton (YAML or JSON, pick your poison). This will have all of the required sections like info
2. Pick your first endpoint and define it in the paths section. Probably start with during simple like a GET. This will mean that you mainly have to worry about defining your responses (at minimum HTTP2XX and HTTP4XX, preferably with a catchall error response for HTTP5XX responses) and their schemas.
3. Run the code generator. This should generate files with stubbed-out definitions for interfaces (or the equivalent for your language of choice) for your response methods. Generally, you do NOT want to add any code to these files as they will be overwritten anytime you update your API spec.
4. Implement the methods to handle the stubbed out interfaces. Ex. A hello-world interface would likely need to be implemented with a method or function that returns the string "hello world".

The reason that I recommend OpenAPI in writing REST APIs is that it helps to layout the API contracts before you even start coding. This helps with keeping typing consistent, give you a clear milestone for implement, and makes creating clients really easy.

Extra benefit is that OpenAPI is (mostly) language agnostic, so, as long as you have a codegen or some good boilerplate, you can use it for any language, which can give you a safe place to start when learning a new language.