What are API Anti-Patterns?

Software design patterns are the solutions used to tackle common software development problems. Design Patterns aren’t strictly required for running code but they are essential to avoiding problems in your code.

On the other hand, bad practices in software development are known as ‘anti-patterns’. Code that suffers from anti-patterns means you waste time and energy trying to share code that is hard to understand and even harder to use effectively. 

Anti-Patterns seem like obvious things to avoid but they can sneak into your code because an anti-pattern sometimes makes things easier for a short term fix. It’s the software version of sweeping dust under the rug. Eventually you will have to deal with it.  

That’s because anti-patterns aren’t bugs. Code that is full of the worst anti-patterns can still run successfully and you can even ship out the code to production.  but ultimately it makes more work for you as you struggle to continue iterating and improving your current code. 

This applies to APIs as well. Anti-Patterns in your API designs make your code vulnerable to serious problems.  Here are some common ones to watch out for. 

Using bad methods

Your API is a collection of methods. GET/PUSH/PUT/DELETE are the most common methods a developer might use in creating a REST API and while those methods may seem self explanatory you should always take care to ensure you’re using the most appropriate methods when writing your requests. 

That can include tunneling requests through GET requests. You write a GET request to provide a resource and then manipulate the resource inside the GET request. 

That is an anti-pattern because it does not communicate to others that once they receive the resource they are supposed to do something else. 

Bad Error Codes

Another insidious anti-pattern is mis-using or failing to use proper codes when sending responses. 

The HTTP Response codes are the magic numbers that can tell a developer the nature of a bug or error in an API request or provide more information about a successful response. Many people know that a “404†error is when you navigate to a page that may not exist but fewer might know that is because error codes that start with a “4†are reserved for a wide variety of errors. 

If this is your first time dealing with response codes then it’s a good idea to review some of the major ones. It can save you a lot of work to simply return the established error and save yourself the work of recreating common codes. 

On the other hand, it’s a good idea to think about use cases in your API for unique error codes. You can create your own but before you start coding you want to consider what information you want to convey and how a future developer can put that to good use as they fix their errors. 

That’s because API development doesn’t just stop when you get a good response. It’s about knowing what to do when something goes wrong and descriptive error codes are a crucial part of that. 

Failing to Cache

Not preparing your API to scale as it grows is another anti-pattern that can dramatically slow down or stop your development. You can add more resources as requests increase but that adds costs and back-end complexity that can quickly spiral out of control. Suddenly you have an anti-pattern in your API that will eventually lead to errors for some users who will have trouble making requests. 

Instead, think about ways you can institute good patterns for growth as you build out your API. That can include caching requests so that users can get access to common requests faster. Or consider requiring authentication from users so that you can ensure people are using your api because it has information they want rather than just grabbing whatever they can. 

Docs

Finally, one of the worst anti-patterns you can create has nothing to do with code at all but with documentation. Bad or non-existent docs for your API can render your API useless for all but the most intrepid (and desperate) of developers. 

You have to ensure your docs provide what developers want and need. That means clear descriptions of what each method does and what resource is returned. You also want to ensure developers can get to developing quickly rather than hunting through a dense library of docs. 

Developers want to start making calls right away and good docs let them do that. 

These are only a few of the anti-patterns you should try to avoid. Unfortunately, we will probably never run out of new anti-patterns but if you incorporate good patterns in software design and development you can avoid these anti-patterns and more. Happy coding!