Getting to grips with making REST API calls felt like finally being able to have a real conversation with the internet. At first the whole thing was a bit too much but once I started to see the patterns emerging, it just became second nature. It all clicked when I realised that a REST API is literally just a way for two computers to swap info over HTTP, same as how your browser does when you browse a web page. The only difference being you’re using a browser to tap links & fill in forms, whereas REST involves sending structured HTTP requests which is to say requests with methods, urls, headers & often a JSON body – & then carefully checking the responses that come back. Knowing that REST is a design philosophy sets out certain rules, like the server can’t keep track of the client between requests (that’s statelessness), all requests need to contain what they need & responses should be cache-able where possible. All this makes communication faster, more predictable & just easier.
At first, the idea of “resources” was a bit confusing, but it soon made sense when I thought of them as real things like individual users, posts or orders; each one with its own url pointing to a specific thing on the server. A REST API shows you these resources through endpoints like “/users” or “/users/123” & then you’ve got HTTP methods like GET to read, POST to create a new thing, PUT to tweak or replace something that exists already & DELETE to remove it. Learning the CRUD mapping was a huge turning point for me – that is: GET to fetch stuff, POST to create, PUT to update or swap something in for an existing one & DELETE to nuke it off the server. Once I got that bit, reading through API documentation stopped feeling like trying to decipher a random puzzle, it just started looking like a sensible system of nouns & verbs working together. Even just looking at a new API for the first time stopped feeling like wandering around a completely foreign city with no map.
Seeing real examples in action was a huge help in making APIs less complicated once I started playing with JSON & responses weren’t just looking like those unreadable blocks. A typical call started to look like a real conversation, you send a request in with a method & url, sometimes adding a JSON body like { “title”: “My first post” } to spice things up & the server sends back a status code & a JSON representation of the resource or an error message. Seeing status codes like 200, 201, 400, 404 & all that as part of the API language was a big help. It made them from being just random numbers to actual signals about what had gone right or wrong. Initially, the idea of REST APIs being stateless (which means the server doesn’t hold onto the client in between requests) was a bit scary, because it sounded like losing useful context but once I twigged I didn’t need to lose any useful context because each request had to include all the details the server needed to do its thing like tokens, params & in the body, it started to all make sense.
Over time, this combination of theory, experimentation, and repetition turned REST from a confusing acronym into a core skill. It’s still evolving, especially with more advanced topics like authentication, pagination, and error design, but the foundation now feels strong.
Resources:
https://strapi.io/blog/restful-api-design-guide-principles-best-practices – I Chose it for its guidance on modeling resources as nouns, designing predictable URLs, using HTTP methods correctly, and handling versioning.
https://devhunt.org/blog/rest-apis-serving-json-a-beginners-guide – Chosen for their clear explanation of JSON request and response bodies, which helped shape the parts of the blog that describe sending and receiving data in a conversational, concrete way