Easy API Development Is Simpler Than You Think

So you want to build your first API. At some point in your pursuit, you've thought about how to make your API development easy. It can’t be too hard; everyone’s doing it. But as you travel down the road, you’re going to face some serious choices.

Most developers creating their first real API assume future-proofing will be their primary concern. Factoring in future upgrades and extensions is a real development issue, but it’s far from the only one. And it’s not even close to the most important at the outset.

As you begin building your API, you should be far more concerned with locking down security, choosing the correct protocol, and understanding how the API will support your application’s business model. Thankfully, here at Mertech, we can handle those things for you with these three ways.

1. Security Comes First

In this day and age, API security can’t be an afterthought. From the start of your project, encryption, authorization, and authentication should be foremost in your mind. After all, that’s how you’ll protect your (and your customers’) data. But your exact implementation could vary wildly, based on your needs.

If you’re serving your API over HTTP (Hypertext Transfer Protocol), encryption might seem straightforward: You’ll be using HTTPS (Hypertext Transfer Protocol Secure). At least, that’s probably the consideration you’ve given the topic. But consider this.

HTTPS uses a cryptographic protocol called TLS (Transport Layer Security). TLS’s predecessor, SSL (Secure Socket Layer), isn’t used at all anymore. SSL’s considered insecure, and most modern browsers block web pages that use it. Now, there are many different versions of TLS, 1.0 to 1.3. You should never use 1.0 if possible, and honestly, you really shouldn’t use 1.1 either. 1.2 and 1.3 are both broadly used, but each also allows you to use different ciphers. You’ll have to choose your cipher wisely. RSA and ECDSA with AES (I’m going to stop spelling out these acronyms now; you have Google) are standard. RC4 is insecure. 3DES is weak, and you should avoid it. At the back of all this, you’ll also need to provide a sane fallback method, so your API can function using older, less secure cipher/protocol combinations when connecting with older clients.

2. Choosing the Right Protocol

Do you know who will consume your API?

You should, because the answer affects the choices you’ll make during API development, including what protocol your API should use.

Consider an API that’ll be consumed primarily by your own developers and applications. In this case, where you fully control both ends of the connection, it’s best to choose a protocol that’s fast as possible and works with the programming languages you use. Unless you need to consume your API from a browser, there’s no reason to use something like JSON. You can use something a bit more complex, like Apache Thrift, which provides a fast, capable connection and support for dozens of modern programming languages.

But what if your API is going to be used mostly by developers outside your company and over the web? Then, you’ll want to use a protocol that’s simple, human readable, and broadly understood. RESTful and JSON-RPC APIs may not be quite as fast as those using Apache Thrift, but speed isn’t the important factor here - accessibility is. Choosing these “simpler” protocols lowers the barrier to entry for your API, increasing its market competitiveness.

If, on the other hand, your API is meant for enterprise-level use, you might have no choice but to serve it via SOAP. Enterprise-level software often requires SOAP access, even from third-party APIs and applications.

What all this means, is your choice of protocol greatly affects who can use your API and how they’ll interact with it. So you need to think about this choice BEFORE you begin building your API.

Your choice of protocol might even limit the tools you can use to build your API.

This is one of the reasons why other developers consider Thriftly to be so groundbreaking.

With Thriftly, you don’t need to worry about choosing a protocol. You simply write your API, and Thriftly translates calls into the proper protocol for you based on your needs at the time. Thriftly even allows you to serve your API using multiple protocols simultaneously.

Thriftly eliminates protocol selection from the API development equation, simplifying things for developers who just want to create quick and easy connections.

3. Designing for Your Application’s Business Model

Next, you’ll want to consider how your application is distributed, an important but often overlooked factor in API design. Even the easiest distribution scenario, where you’re already hosting your application in the Cloud, requires careful planning and consideration.

For instance, do you store your customers’ data on separate servers? In separate databases? Keeping this data isolated, while also connecting it with the same API, will affect your API’s design.

In contrast, many independent software vendors sell software that must be installed on-premise. Providing an API in these on-premise environments can be especially challenging. In most cases, you won’t control the environment’s hardware or network configuration. Getting an API to function properly, and connect to the Internet, from inside a network you’re unfamiliar with can be challenging and time-consuming.

Now, multiply that difficulty to match the hundreds or thousands of different customers and networks you need to support. All of a sudden, you’re looking at hiring one or two full-time support staff members, just to roll out your API.

Again, Thriftly can solve these problems for you.

For the Cloud scenario, Thriftly’s pool-based structure allows you to isolate your application at either the database or server level, using startup parameters. To handle on-premise deployment, each Thriftly subscription includes access to our global network of gateway servers, allowing you to automatically serve your API over the Internet without having to worry about network or server configuration. As long as a computer running Thriftly has access to the Internet, it can connect to a Thriftly API.

Without the arduous and error-prone process of network configuration, rolling out your API will be a cinch. Additionally, Thriftly’s PowerShell scripting interface allows you to automatically distribute and roll out your API, without worrying about each and every customer’s unique network configuration.

Need more layers of security for your business?

If the answer is yes, then you’ll need to implement an authentication method (so users must prove they are who they say they are) and an authorization method (so users are allowed to do only the correct things within your API). Will you ask users to authenticate with just a simple username and password, or something more complex and secure? Will you use cookies for authorization, or a session table? Do you have machine-to-machine API support that will require a pre-shared key of some sort? These are only the basic questions. The security rabbit hole goes much deeper.

All these details matter, and they can be incredibly hard to keep track of. That’s why we consider it so valuable that Thriftly handles security for you.

For instance, Thriftly includes JSON Web Token (JWT) support specifically to help you handle authentication and authorization. This is more than just a checkbox feature for us, because we know it’s more than just a checkbox feature for you, the budding API developer. 

Conclusion

Simplifying protocol selection, ensuring you can connect to your API regardless of your business model, and streamlining security are just some of the ways Thriftly can support you as you develop your first API.

We also offer a number of other features and resources, including more blog articles, tutorials, case studies, and the Thriftly docs. And if you’re really puzzled, don’t hesitate to contact us. We know that, regardless of the fact that everyone else is doing it, API development is tricky. With Thriftly, you don’t have to go at it alone.