This blog and this website are built on an API

This blog is being served up by an API.  This might not seem like a big deal, but… it kind of is. You see, there is a LOT of full stack development out there. “Full Stack” is when you build everything together: you build a database, the way you connect to that database, the code that uses that connection to get the data and display that data to make it something humans can read. 

It's kind of a dirty secret that the tech industry has been using things like Drupal and WordPress for eons for basic content websites. But even newer frameworks like React weave the frontend, the code and the data layer all together into one mishmash of components that are hard to modify without affecting some other part of the app.

There’s also the whole security issue – relying on the same code that gets the content to be the gatekeeper to manage access to that content is kind of a fox and henhouse situation.  If I want to hire a developer, I have to give them the keys to the entire user base and all their content… which is, unfortunately, the start of a lot of security breach stories. 

So, after years of building APIs for other people, but running my own website on an antiquated full stack, I decided to test my own API platform and rebuilt my website on a RESTful API. It’s not a very complicated API… It has one collection called “pages” which I just segment using categories. 

Go ahead, the ability to GET isn't restricted, so you can look at the source json on api.michaelbisell.com like this:

GET https://api.michaelbissell.com/v1/pages/167d7c20-8cc2-11ed-b6fc-b5eee5a22130

Because the API follows some basic standards I'm able to query and sort with things like

GET https://api.michaelbissell.com/v1/pages?category=blog

And if you'd rather not start with my posting from 2008, you can sort the newest to the top of the list with

GET https://api.michaelbissell.com/v1/pages?category=blog&sortBy=posted&sortOrder=desc

The standards also include pagination and other basic, reusable functions. It doesn't matter if I'm rebuilding my blogsite with 15 years of ramblings, or building a recipe app, the consistent standards make it easy to reuse code without having to do a lot of custom coding. 

All of this is driven from the API contract – the rules for what fields are part of a page are outlined in the contract including the formats like the fact the main body of the blog is in markdown or the socialimage field is an image. Yes, it's documentation that a developer can use (I peeked at the contract to remember if it was “pagesname” or “pagename” ), but it also defines the rules for the API itself so I don't accidentally post pagename when I meant pagesname, and it informs my editing tools so in the admin secition of this website I see a nice, rich text editor for the blog and an image upload button for the socialimage. 

And then there's the core security tools that don’t have to be(and shouldn't be) integrated into the application itself.  The security is defined for objects, like this blog posting, and rules for who can POST or DELTE are defined by the API, not this website. The app never sees the authentication OR authorization (that's a topic for another day – but it's amazing to me how many authorization models, the actual enforcement of the rules, are left up to the app).

The idea is that data presentation and data access are two very different disciplines.  I am, admittedly, not really a front end developer – I take freebie templates and drop code into them. But because I have a RESTful API that I can literally call to with a couple lines of code, I can play with the presentation layer without worrying about how I'm going to manage the access to the actual data.