RESTful APIs or not?

First, let’s clarify the difference between RESTful and non-RESTful APIs.

Wikipedia says:

In computing, representational state transfer (REST) is an architectural style consisting of a coordinated set of components, connectors, and data elements within a distributed hypermedia system, where the focus is on component roles and a specific set of interactions between data elements rather than implementation details. Its purpose is to induce performance, scalability, simplicity, modifiability, visibility, portability, and reliability. REST is the software architectural style of the World Wide Web.

In simple words, RESTful is just a bunch of architectural design principles which say you need to use HTTP methods such as GET, HEAD, POST, PUT, DELETE, and others properly, make use of the HTTP status codes, construct your routes (URLs) in a certain fashion, etc. This makes sure you are following standards strictly making everybody’s life a lot easier. Just for the record, I’m all in for RESTful, big supporter. BUT… But as long as your APIs are easier to consume, logical, consistent, secure, and work as expected, you have nothing to worry.

Should you have public RESTful APIs?

Now let’s see if you actually need to have APIs in your project and if you should expose them. While this is completely a business decision, it’s good to build the back-end of your system with RESTful principles in mind. I’ll tell you why.

Today you might be the only consumer of your services. For example, you might have a client, a UI, which needs a back-end to communicate with the DB and source various pages based on various routes. But in the future, there might come a situation where you want to have a mobile app for your project, or you want to sell your service as a platform letting other systems communicate with your service. If your initial architecture is not API-based, you’ll have to write APIs now. You can either have a completely separate project for the APIs, or build upon the existing code base.

If you start with a new project just for the APIs, you’ll face redundancy. If you start modifying the existing code base, well, you’ll have to basically change everything. This example is from my experience. After facing such situations a couple of times, I learned my lesson and start every project today as an API project. If you have APIs in place, you don’t have to worry about the different types of clients consuming those APIs.

If you have a web-based UI for your project, you could still have your back-end as an API engine and use one of the hundreds of front-end frameworks for building your UI (thing AngularJS, ReactJS, etc.). This would let you keep the back-end and the front-end independent. According to me, this is the best architecture you could adopt today. It would take a whole different post to discuss why I love this architecture.

Anyway, to summarise, it’s best to have APIs for your core services if you are going to have multiple clients, or if you are going to open up your platform for third parties. If you ask me, ALWAYS have APIs!

Advantages?

Let’s see:

1. Easy to maintain as the back-end and front-end are independent entities.
2. You can have two different teams working independently on the front-end and the back-end.
3. You are not restricted to using back-end-front-end compatible technologies. Which means the technologies used for the back-end and the front-end could be different, without any issues.
4. The same back-end service code base could be used to serve multiple clients.
5. If you go the RESTful way, you’d be following the best standards in the industry. This will make you write some good quality code.
6. The consumers of your APIs will be a lot happy.

No more FTPs, CSVs, and scraping

In the olden days, when you had to get data from other services, we used to download CSVs from that service’s FTP servers, parse the CSVs, and handle the data however we’d want. This is dying out. Yes, we still use this today. I’m working on a project which has a few tens of source-providers, all using different methods. I have to download .txt files, .csv files, .xlsx file, and what not! In some cases, I have to get IDs from a .csv file, call a RESTful API, get some data and another list of IDs, download a .xlsx file from an FTP server, and then use the IDs from the API response to find the data in the .xlsx file.

It’s easy to write the code which does this. There’s libraries for everything. But this is not the right architecture. A lot of pain points, and a lot of places where something could go wrong and break the whole system. But yes, this is a legacy system.

If your consumer base is good, if you can justify rewriting your services to expose APIs to your consumers, you should probably do that.