Lately, I have been working on rolling out a web API for everyone at work to use. It is important to note that sometimes we forget what to include in our API’s. Today I pose some thoughts, to keep in the back of your mind, for designing web services.
There are a few things we take a back seat on that are very important to think about in your projects:
Consider what your security options are for your API. Did you know that Transport Level Security has some man in the middle attack issues? If you want to make sure you authorize the correct person, then maybe Message Level Security is best. What if you want to encrypt the message, aside from SSL? What will AES do for you? Do you even need any of this? Sometimes you need to ask these question to understand the problem better. If you do not have sensitive data, then AES may be overkill, but SSL is perfectly fine for most things. Discuss these things, first, not later.
To know what is going on in your API, it is important to throw in some telemetry to collect this data. In my previous article, Doing some Telemetry, I discuss some items to collect for an application. I think telemetry, overall, is an art, so your needs are going to be different. It doesn’t hurt to have a base level to start out with. Do you know when your applications busy time is? Maybe you should check out some telemetry to get a history of when your app is used most.
Everyone has this one client that spams the hell out of your application. Wouldn’t it be nice to just stop them before they stop you? That’s what Rate Limiting is. This also allows you to make sure you can hit your server’s upper limit, without breaking your server. If you combine this with telemetry, you can really start to shape your traffic and guide when you need to upgrade. Hell, you could even sell access to more “queries”, if you wanted.
In http, this is almost free, because each web server providing access to compression. But if you are not using http, it is important to know that you should have compression. Compression becomes very important when you are using wordy languages like XML or HTML. Even if you are using http, sometimes it is easy to skip over gzip, so be sure to consider this piece.
Caching is great. It allows my site not to get hammered and blow up. But there are 2 levels of cache to be aware of, database, and web page. At the database level, you could use an in-memory cache like Redis. You could also just have a dictionary, but this does not scale well. All of this will make sure that your database is not hammered, as well. Next, there is web page caching, which is at the http level. It’s awesome because then you don’t rely on your machines to do the caching, but the internet! At least consider where you are caching for your applications.
Overall, think about these things when creating a web API. Most of the time we skip over this stuff, but these are important if you want to get serious about your code. At least have the conversation to see which are important. You would be surprised how much better you will feel, once you do talk about these things upfront.