Mistakes are unavoidable in the development world and can create a variety of problems for developers and their end-users. Even small mistakes can have far-reaching consequences.
If you’re building an API, here are 6 common mistakes to avoid.
1. Scraping data from the wrong sources
When creating any kind of API that collects or aggregates data, make sure you have explicit permission to access and use the data directly from your source. There are endless sources to scrape data from, but be extremely cautious about public sources.
Depending on your industry, the wrong data source can create severe problems. For example, Patrick Collins from Alpha Vantage warns against scraping data from public sources if you’re creating a stock API. Public financial data tends to be unreliable and might even be illegal.
Current laws that govern content on the internet aren’t as up-to-date as they should be, and so the legality of data scraping is a bit ambiguous. However, the Computer Fraud and Abuse Act (CFAA) prevents many instances of data scraping and courts have ruled against using data scraping software in certain ways.
Public data may not be public
Just because a data source is publicly available doesn’t mean it’s available for public use. That data might ultimately exist behind a paywall or require a user account to access. If someone finds a way to make protected data publicly available when they shouldn’t, you can still get in trouble for using that data.
2. Making a simple sprite coordinate mistake
It’s always the small things that get you in the end. This is a lesson most programmers know well. Virtually every programmer can tell you a story about how they made a tiny mistake that had devastating consequences.
A former Google programmer on the App Inventor team made an embarrassing mistake with misplaced sprite attributes that couldn’t be fixed without affecting existing app installations. Ten years later, the programmer implemented a patch.
App Inventor is a drag-and-drop programming environment for novice programmers to build Android applications. In a rush to meet a projected release deadline, the programmer began implementing sprites.
Naturally, the image sprites were created with x-and-y coordinates at the upper left corner on the canvas. However, the programmer used the same positioning for ball elements rather than placing the coordinates in the center of the ball. This small mistake caused app users to do extra work in their apps that used the ball component.
3. Forgetting to use HTTPS when testing an API
Some APIs support only HTTPS. Forgetting to use HTTPS rather than HTTP when testing an API can cause plenty of errors.
According to DZone, some APIs automatically redirect HTTP traffic to HTTPS, but not all frameworks are configured to follow a 302 status code to redirect. For instance, the Node.js request module follows GET redirects, but you must set followAllRedirects to true if you want to follow those redirects to POST or any other methods.
If you’re creating an API, make sure it supports HTTPS even if you’re not handling personal information. It’s easier and cheaper than ever to get an SSL certificate up and running so there’s no reason to skip HTTPS.
4. Not using familiar status codes across multiple APIs
Developers interested in your API will learn your API easier when it’s built using conventional standards used by other APIs. For instance, you don’t need 50+ status codes. You can use standard codes like 200, 400, 500, and add codes that already have existing meanings within other APIs.
You may have noticed using another developer’s API turns up 200 status codes, but there are still errors. Don’t use error codes out of context from what people are already used to seeing. It’s imperative to make sure your status codes are both meaningful and recognizable.
5. Unexpected error codes with no explanation
Error codes aren’t a big deal when they’re accompanied by some details. Error codes without an explanation will drive developers crazy trying to figure out what they’ve done wrong.
To support developers, always provide explanations and links with your error messages.
6. Mixing up Authentication with Authorization
This is a simple mistake that happens frequently. The words ‘authentication’ and ‘authorization’ serve entirely different purposes. However, the words are similar and easy to mix up on autopilot.
If you’re experiencing failed authorization requests, check to make sure you’ve included Authorization headers where appropriate.
Test often and fix mistakes early
Testing often and fixing errors early is the best way to avoid mistakes that negatively impact the use of your API. The developers using your API will expect your work to be professional, consistent, and usable.
Build your API for your developers. Your API doesn’t need to be pretty, but it does need to work.