Building a Scalable, Secure API (without writing code)

In the first three posts in this series, we looked at what APIs are, how to use them to move data in the cloud, and how to migrate data via APIs. In this post, we’ll look at how (and why) to build your own API.

Why should you care about creating APIs?

FME allows you to connect data and applications without writing any code. While this is extremely powerful, the workflows you create do not provide an easy way for developers to interact with your data.

As discussed previously, to be successful in the modern enterprise, you need to provide a stable, clear interface to your business for developers. APIs allow businesses to build platforms that partners and customers can use to access core business systems, whenever they want, in a stable and secure way. Another benefit APIs bring is that they abstract the internal implementations, so you can make changes to internal behaviour without impacting customer implementations. This is important, as if you decide to migrate the data store, you can migrate the data and then connect it to the original API, and the user can keep using the API. This decoupling lowers the risk considerably for consumers of the API.

Creating an API has now turned into a commodity, with many vendors such as AWS and Azure providing services. The complexity therefore lies not in creating the API, but how to connect the APIs to the data. This part is not trivial and was traditionally done with code, but with FME you can connect an API to hundreds of data sources without writing any code.

When is the codeless API a good fit?

There are many ways you can go about building and hosting an API. We are focusing on the codeless and serverless model using AWS API Gateway in conjunction with FME.

To assess if this is a good fit for your scenario, here is a checklist:

• You wish to allow developers to access your data and processes.
• You don’t have access to developers and want to do everything within a GUI.
• Agility is key and you wish to create disposable APIs that might only last a short duration—say the lifetime of a project.
• You are prototyping a new service. Don’t just put a website up for beta users—get an API in front of them. APIs are much stickier than web apps. If you can get beta users to integrate your solution into their workflows, you will have a higher chance of retaining them.

A serverless and codeless API is probably not a good fit if you want to create a large complex API that is going to serve a significant user base with millions of requests, as you will need more control to ensure you can optimize.

Watch the webinar recording, where we use FME Cloud and Amazon API Gateway to create a stable, scalable API on top of a PostGIS database without writing code. The code samples for the webinar are available on GitHub.