Skip to content
Sunday, April 11
  • About Me
  • Must Watch Videos
  • Proof of Concepts (POCs)

The Tech Check

Tech from one dev to another

The Tech Check

Tech from one dev to another

  • Data Science
  • Tech
  • General
  • Proof of Concepts (POCs)
  • About Me / Products
  • Must Watch Videos
  • Data Science
  • Tech
  • General
  • Proof of Concepts (POCs)
  • About Me / Products
  • Must Watch Videos
Trending Now
  • out() vs. outE() – JanusGraph and Gremlin
  • Getting Started With JanusGraph
  • I made a website which tells if you’re wearing a mask or not – without machine learning
  • Free apps vs. Paid apps
  • Binary Search Tree Implementation in Java
  • Different ways of iterating on a HashMap in Java
Home>>Tech>>It’s time to move your platform to RESTful APIs
Internet/WebAPIs
Tech

It’s time to move your platform to RESTful APIs

Sunny SrinidhiAugust 21, 2016 625 Views0

If you are into tech, there’s a good chance you already know what’s a web API. All the cool kids use it these days. It’s the new kid on the block. And it’s sexy with well defined features.

Web APIs aren’t necessarily new, they’ve been around for a while. Even RESTful APIs aren’t that young. But that’s not what we are here to talk about. We are here to see why it’s time to move your platform to a more modern architecture which exposes a bunch of (RESTful) APIs for the rest of the world to add value to your platform.

As a person who’s been producing and consuming APIs for the last few years, I’ve seen a lot of them. I’ve had projects where I was required to get and send data to third party servers, and this is where RESTful APIs come in. I’ve seen tens of thousands of them, scrolled through thousands of pages of documentation. All this frustration has led me to write this post today.


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.


I know I’ve not been very convincing here. But trust me, RESTful APIs are the future. You need to move to writing and using RESTful APIs as much as possible. Maybe, I’ll write another post to explain how to write one. Also, documentation is equally important.

About the author

Sunny Srinidhi

Coding, reading, sleeping, listening, watching, potato. INDIAN.
“If you don’t have time to do it right, when will you have time to do it over?” – John Wooden

See author's posts

Share this:

  • Twitter
  • Facebook

Like this:

Like Loading...

Related

Related tags : apismicro servicesprogrammingrestrestfulrestful apisrestful web servicestechweb services
Share:

Previous Post

Why I love curly brackets

PHP Code

Next Post

When I finally get to use my master’s degree

Graduation

Related Articles

Tech

Sending messages to Amazon SQS from a Spring Boot application

amazon athena Data ScienceTech

Query data from S3 files using Amazon Athena

Tech

Receiving messages from Amazon SQS in a Spring Boot application

Programming RantsTech

/public/api/v1.2.3.4.5/login — Don’t do this!

load balancer Tech

The art of load balancing – Part 1 (Understanding a load balancer)

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

O’Reilly Live Online Training

Getting Started with Amazon Athena

by Sunny Srinidhi
23rd April, 2021
Register now here
Sunny Srinidhi's DEV Community Profile
AWS_Community_Builder

Follow Us

  • Twitter
  • LinkedIn
  • Medium
  • GitHub

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 20 other subscribers

Recent Posts

  • out() vs. outE() – JanusGraph and Gremlin
  • Getting Started With JanusGraph
  • I made a website which tells if you’re wearing a mask or not – without machine learning
  • Free apps vs. Paid apps
  • Binary Search Tree Implementation in Java

Categories

  • Data Science (43)
  • General (4)
  • Rants (6)
  • Smartphones (1)
  • Tech (71)

Archives

  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • October 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • June 2019
  • May 2019
  • April 2019
  • November 2018
  • August 2018
  • July 2018
  • August 2017
  • July 2017
  • June 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • September 2016
  • August 2016
  • March 2016

Tags

ai amazon apache apache kafka apache spark artificial intelligence aws best practices bigdata big data coding data science datascience data structure implementation in java data structures feature reduction feature selection java java data structures java data structures implementation java linked list example java linked list implementation javascript kafka linkedlist linked list in java linked lists machine learning machine learning models ml natural language processing nlp php programming python scikit python sklearn rants scikit scikit learn sklearn spring spring boot tech technology the fasttext series
Sunny Srinidhi | WordPress Theme Ultra Seven
%d bloggers like this: