Chapter 11 - API and other issues

I spent some time trying to get it to work. I made the following changes:

class EONET {
  static let API = ""

struct EOCategory: Decodable {
	let id: String

struct EOEventCategory: Decodable {
  let id: String

struct EOEvent: Decodable {
  let id: String

Even with those changes and a few hours of work, the app did not want to download the events for some reason.

Did anyone figure it out?

There can be different API errors, and here we will tell you more about 5 the most popular ones:

Incorrect HTTP Method
The simplest, yet widely spread API error is the incorrect HTTP method. Frequently, the issue is caused by gaps in the documentation. One of the examples may be sending a GET request specifying the data option, but skip mentioning -X GET parameter. As a result, it gets automatically converted to a POST request. Also, the issues with HTTP methods may occur when switching the API tools because some of them may use one method for creating test environments and modifying them, while others use separate ways for these actions. That is why it’s important to carefully check these nuances, as well as adopt a consistent approach to writing your own documentation.

Using the wrong protocol
Another common error is the discrepancies between https:// and http:// protocols. Some APIs may support only one of the protocols, let’s say http, so specifying https:// in such case will lead to incorrect request processing. Even if both of them are supported, there may be issues with the redirect to https:// when you specify the http://. The case may also occur when providers of third-party APIs you are planning to use make some changes and fail to send a notification about that. So it’s better to re-check these aspects from time to time. For creating your own API, it’s better to use https:// protocol. To make it possible, it’s required to install an SSL certificate to the host. Some time ago, SSL certificates were a bit costly so there could be doubts regarding it, but with free providers like Letsencrypt or Cloudflare, it becomes easier than ever.

Absence of meaningful error messages
If you have ever faced an “unexpected API error”, you know how annoying this one may be. Usually, error messages are supposed to facilitate troubleshooting for the developers pointing out the exact reason for the error or at least where to search for it. Unfortunately, such uninformative errors can result in hours of wasted times, increase the time required to solve the error, and consequently cause a bigger spike in the negative feedback you receive, that is why it’s better to spend a bit more time on describing the potential errors and making the messages informative for those who will need to troubleshoot them. While there exist several dozens of HTTP error codes, it’s not required to use all of them, but keep the standard error codes (200,400, and 500) and consider including the hints into the messages so that even in cases when something is not working, it’s possible to quickly find out the root cause of the issue.

Authorization trouble
It may seem that here everything is clear as wrong authorization usually presupposes that the username or the password is incorrect, but in fact, even confusing “authorization” with “authentication” in headers causes the error. It’s especially valid in using the OAuth 2 protocol. Also, the syntax matters, because some simple yet less obvious things can create confusion. In most cases, these are the bearer token, the space in the “Basic ” prefix, missing to add this prefix completely, and losing the colon in the “username: password” pair. Even when the username is used alone in some APIs that do not require the password, you will still need to use this colon.

Failing to specify the Content-Type and Accept headers
Some APIs are tolerant to the requests where headers do not contain Content-Type or the Accept header but correspond to the allowed data format. Others are more scrupulous and will not let the request through giving out the 403 Permission Denied error code. At this stage, the interaction between the client and the server regarding the expected data type in the request and the response is established. This header check is implemented to lower the risks of security breaches and overall hacking attempts, that is why it’s better to specify these headers to avoid any troubles during use.

Rachel Gomez

This topic was automatically closed after 166 days. New replies are no longer allowed.