Looking back on last week’s Rocket MultiValue University, it was obvious there was a lot of interest in building web and mobile applications. In all my sessions and personal conversations, including the very popular CAB, I found myself repeatedly saying, “that’s why APIS to your database are great.” It’s because it doesn’t matter the language/framework of the client, since RESTful APIs are universal and easily consumed by any technology. So I thought it would be a good idea to talk a little more about why I think APIs are a great thing when you’re looking at building any kind of client application.
Public APIs for utility and social applications have been prevalent for quite a while. Let’s take Google Maps API for example. By exposing a public API to their maps application, they’ve invited a host of companies to build interesting solutions by leveraging Google Maps technology and adding contextual content on top. As a good example, CrimeReports.com uses the Google Maps API to allow you to view publicly available crime reports within a certain area and interact with the map to find out more information, definitely useful if you’re looking to move into a new neighborhood!
Another example you can find right here on this page are all of the social interaction sites such as Twitter and Facebook. Twitter exposes APIs that allow you to embed functionality to let the user easily share content on their site without having to know the gory details of how Twitter implemented each piece of technology.
Implementing a public API adds to the viral capability of your application by giving easy access to applications that don’t need to know anything more than how to interact with your API. This is great if you have a publicly facing application, but not everyone needs or wants to expose their technology to third parties.
More of what I talked about during MVU was creating APIs as part of your internal application architecture and the value that brings. Even if you’re not going to expose your application to the outside world, creating APIs for your MultiValue application can have some benefits that you may want to consider. Here are just a couple points to highlight:
- Loose coupling-A clean separation of duty between the client and server allow client developers to be free from worrying about programming language or platform. The client and server may be developed and replaced independently of each other as long as the interface remains the same. This means you could hire an external web or mobile development company to do what they do best if you wanted, saving you the ramp-up time of trying to learn those new worlds.
- Reusability-The same API could be used to drive a web application, mobile application, or be exposed to outside parties for partnering or extended development if you so desire.
- Layering-APIs could be part of a larger chain of functionality, the more granular the services, the more combinations of things you could build independently.
- Uniform interface-Having a common interface simplifies access for any client applications, which only need to know the interface. This can simplify testing as well.
- Centralized Administration-Having one place for clients to interact allows you to more easily control tasks and policies like security, testing, deployment, monitoring, etc.
Luckily, MultiValue data is a great fit for Web service APIs, since the embedded nature of MV closely resembles the structure of JSON/XML/SOAP.
RESTful APIs are easy to create in UniVerse, UniData, and D3 alike. This comes in very handy when working with things like Rocket Mobile, where REST is the way to interact with the database. UniVerse/UniData can use U2 Web DE, SB/XA, or U2 RESTful Web Services developer to quickly create an API based on files and subroutines. D3 has the MVS Toolkit which similarly creates Web services in either REST or SOAP style.
At MVU, I also showed how you could consume MultiValue Web services from popular frameworks, such as AngularJS or Node.js, really opening up the world to develop your applications and interfaces in whatever technology you desire. Specifically, I was working with U2 RESTful Web Services that create a JSON output, which is usually what I recommend if you pushed me to suggest which format to go with.
Hopefully you can see the value of exposing at least part of your application as an API when you need to interface with any development outside of your database server. There are many more arguments both for and against APIs and which style, but I just wanted to give you my quick take on why I thought APIs might be a good idea for you. Have fun!