Let me be honest up front. As a digital analyst, you will almost never build a REST API. That's a developer's job, and that's fine.
But you call them constantly, whether you notice it or not.
Every time you pull data from the GA4 Data API, push an event through the Measurement Protocol, or wire a Google Ads connector into Looker Studio, there is a REST API doing the work underneath. When something breaks, the error you see is a REST error. When you hit a wall pulling reports, it's usually a REST limit.
So the goal here is not backend depth. It's practical literacy. Enough to read the docs, call an endpoint, and understand why it did what it did. That's it.
REST stands for Representational State Transfer. It's an architecture for web APIs, first described in Roy Fielding's 2000 dissertation. Fielding also co-authored HTTP, which is why REST and the plain web share so much DNA. An API that follows REST conventions is called RESTful. That's the vocabulary out of the way.
Here's the idea that took me the longest to internalise, and the one that matters most.
REST is data-oriented, not procedure-oriented.
Older web services (RPC, SOAP, if you ever meet them) are built around remote procedures you call, like functions living on another machine. REST throws that out. Instead, everything is a resource with its own address, and you act on it with a small set of standard verbs.
You can safely ignore SOAP and XML-RPC in day-to-day analytics work. They exist, they're mostly legacy, and you'll rarely touch them. Good to know the names, nothing more.
So a resource is a thing: a user, an article, a report. Its address is a URI, like /api/users/pepa. And the action you want lives in the HTTP method, not the URL.
The four basic operations go by the name CRUD, and they map neatly onto HTTP verbs. If you've ever filled out a form on the web, you already know these intuitively.
Notice the naming pattern too. Resource names are nouns, usually plural (/articles, /comments), and the verb is the HTTP method, never the URL. Nested relations read like plain English: GET /articles/1/comments/5 means comment 5 on article 1.
And query parameters, the bits after the ?, filter and shape your results. GET /articles?count=100 is the same pattern you use in normal URLs every single day.
This is the part I'd actually memorise, because it saves you the most time.
Every response comes with an HTTP status code. The first digit tells you the class: 1xx is informational, 2xx is success, 3xx is a redirect, 4xx is your mistake (client error), and 5xx is the server's mistake.
The rule of thumb: 4xx means look at your own request first.
Here are the ones worth recognising on sight.
If you take one thing from the list above, take 429.
Too Many Requests means you called the API faster or more often than it allows. It's extremely common when pulling from analytics and ad-platform APIs, especially if you're looping through markets, date ranges, or accounts.
So design for it. Spread requests out, batch where you can, and don't build a pipeline that fires hundreds of calls in a burst and then falls over at 9am on Monday. Ask me how I know.
Some REST behaviour looks strange until you know the why behind it.
REST is stateless. Every request carries its own authentication, and the server keeps no memory between calls. That's why API calls send a token each time instead of leaning on a session cookie. It's also why REST scales and runs in parallel so well.
JSON is the de-facto format. REST can technically return XML or other formats, negotiated through the Content-Type header, but modern APIs speak JSON. That's why you see JSON everywhere as an analyst.
Caching, compression and pagination are all built on plain HTTP. ETag and Last-Modified handle caching, GZIP shrinks payloads, and Link headers plus X-Total-Count let you page through large result sets. When a report comes back in chunks, that's pagination doing its job.
On authentication, the standard you'll meet is OAuth. It's what Google APIs use. There's a simpler option called HTTP basic auth, but it sends credentials in the clear, so avoid it.
This is where the literacy pays off. These are the tools I reach for, and every one of them is REST underneath.
My honest advice: before you wire an endpoint into a pipeline, poke it first. Use cURL on the command line or Postman if you prefer a GUI, and just read the raw JSON that comes back. Seeing the actual shape of the data before you automate anything will save you hours.
You'll sometimes see people argue about whether an API is really RESTful. That comes from the Richardson Maturity Model, which splits REST into levels.
Level 0 is plain HTTP as a transport. Level 1 adds resources with multiple endpoints. Level 2 uses HTTP verbs and status codes properly, and this is where almost every real-world REST API lives. Level 3 is HATEOAS, where responses include links to related resources so the client navigates by following them.
Level 3 is rare in practice. So if you assume Level 2, you'll be right most of the time. Don't lose sleep over the purity debates.
You don't need to become a backend engineer to work confidently with APIs. You need a handful of ideas, and the rest is reading docs.
Here's what I'd keep in your head:
Understanding how data actually moves between systems is a quiet superpower for an analyst. Programming without context is just code. Knowing how the information flows, and being able to read what the API tells you, is what turns a broken pipeline into a five-minute fix.
If you're doing GA4 or GTM work and something in your data feels off, or you just want to talk REST, connectors and dashboards, reach out. Links are in the footer at bmateas.com/contact.
I'll come back to more of the analyst-meets-code stuff soon.