REST is short for REpresentational State Transfer. I confess I didn’t know that until I just looked it up. I’d heard of RESTful services or RESTful APIs and I’d rather naively assumed it was a service resting - literally waiting - to be accessed and provide information.

I’ve picked up my own, probably rather simple, understanding of REST and RESTful APIs over time. I’ve been trying to find a more accurate and succinct description or video of it for myself and this blog and I’m struggling. So I’m going to describe what I understand it to be. I’m hoping I’m correct enough for fellow dinosaurs but be aware you may want to do a bit more of your own research.

Firstly I’m including it partly due to what’s going to be in a blog post soon. And the work for that post made me realise that I’ve been so vaguely aware of REST APIs for so long that I hadn’t even considered how important it might be to include in this blog/journey as a post of its own. So it’ll be a real shame if how I’m about to describe REST is completely wrong!

I consider REST as a way to interact with a service. Typically it’s to ask a service for information. I imagine modern tech businesses like Spotify with all of it’s little individual tribes (that’s a whole bunch of other blog posts in itself) with each group looking after its own little part of Spotify. A group for user accounts and access; a group for building playlists; a group for front end; a group for billing; etc, etc. Each of these things must interact. As a user I’ll hit the front end (different groups for mobile and desktop, I wonder?); I’ll want to see my own created playlists as well as the Spotify curated playlists; I’ll pay my subscription and the app will need to check that’s all up to date; plus it’ll remember where I left off on the last device I used. To me as an end user it all works so well as a single unit but the reality (I think!) is that these are all separate services that are managed and run by separate teams. In order to communicate, each service offers its own RESTful API allowing other services to ask it for information. This means a single team can make any kind of change to its own service as long as the API doesn’t change and responds in the same way and receive information. Want to change you application logic or, God forbid - your database, go ahead, with no impact to the user experience (as long as your API keeps working as the other services expect).

There are lots of more formal descriptions of REST across the web. Sadly I think you need a bit more developer experience than I have to fully understand them. But what I gather, for typical usage, they return data in JSON format and are accessed by HTTP with typical HTTP commands - GET, POST…

OK. I thought I could include an example here. The really cool one I wanted to use isn’t a REST API. But in googling for an example, the ever so slightly different search string brought me back lots more useful links (I was surprised at how poor the results were previously). This video from Clever Techie is really good. Check it out.