The Ten REST Commandments

One of the core things I've been working on for the past 10 years are APIs. Everything from simple APIs that are used by one client to multi device and multi purpose APIs. During those years I've also had the opportunity to work with many third party APIs like Stripe, Twilio and others who are less popular and glamorous 😂. Almost all of those APIs were REST based and unique in some way.

There are many reasons why REST is so popular. It's simple to understand, it's flexible, it works on any scale, it has a great community and tools built around it. But besides those I'd also say that a lot of popularity came from the fact that's it's oldest rival, SOAP, is just horrible. If you've ever used or worked with SOAP - you know! The clients were terrible, people did what they wanted with XML, it's bulky, the auth situation was sometimes wacky...Thankfully JSON and REST based APIs won that battle.

On the other hand there are also newer, more modern players that are trying to take some of that spotlight from REST based APIs. I'm of course talking about GraphQL. GraphQL is also JSON based and shares some of the good traits that REST has like flexibility, performance, scalability...For me personally the two key downsides of GraphQL are that it's built by Facebook and that it shifts the API design process to the client. What I mean by that is that it leaves mobile devs and front end devs in charge of building their own ad hoc APIs and making queries on the database. Don't know about you but I don't think that's the best idea. Don't get me wrong, I love mobile and front end devs, but they might not have a lot of experience with database design, writing queries and building APIs. You probably wouldn't give your back-end dev to design an app, a car mechanic to fix an airplane or a veterinarian to operate on a human person. Could they do it - maybe, possibly. Should they - I don't think so.

Leave a Comment