Tag Archives: website development

Best Practices for API Error Handling

Best-Practices-for-API-Error-Handling

As a web developer, we all don’t want to see Error codes in an API response, neither do you. When it happens to you, it can mean one of two things — there was something wrong in your request or your handling that the API simply couldn’t parse the passed data, or the API itself has so many problems. In either situation, traffic comes to a sudden end, and we start trying to discover the cause and solution for that.

Although being unpleasant, errors, whether in code form or simple error response, are incredibly useful. Error codes are probably the most useful diagnostic element in the API space.

Today, we’re going to discuss about the importance and the usefulness of error responses and handling approaches. There are some common error code classifications the average user will encounter, as well as some examples of these codes in action that you need to know.

The Value of Error Codes
As explained above, error codes are surprisingly, but incredibly useful. Error codes in the response stage of an API are essential in communicating failure from a developer to a user. This stage is a direct communication between client and API. It’s considered as the most important step towards informing the user of a failure, as well as boosting the error resolution process.

An error comes randomly and sometimes it’s beyond our knowledge. That’s why error responses are the only constant, consistent communication that we, as the user, can rely on when an error has occurred. Error codes can both clarify the situation, as well as communicate the intended functionality.

For example, an error code such as “401 Unauthorized – Please Pass Token.” You understand the point of failure in that response, especially that the user is unauthorized. However, you also figure out the intended functionality, which means that the API requires a token, and that token must be passed as part of the request in order to obtain authorization.

With a simple error code and resolution explanation, you have already identified the cause of the error, as well as the intended functionality and method to fix that error. It is very useful, especially for the amount of data that is actually returned.

HTTP Status Codes
Before we deeply discuss about error codes and what makes a code good, we need to sort out the HTTP Status Codes format. These codes are the most frequent status codes that the average user will encounter, not only in terms of APIs but also in terms of general internet usage. Although there are other protocols and have their own system of codes, the HTTP Status Codes dominate API communication, and vendor-specific codes tend to be derived from these ranges.

  • 1XX – Informational

The 1XX range has two basic functionalities. First, in the transfer of information concerning the protocol state of the connected devices — for example, 101 Switching Protocols is a status code noting that the client has requested a protocol change from the server, and that the request has been approved. The 1XX range also elucidates the state of the initial request. For example, 100 Continue, notes that a server has received request headers from a client, and that the server is waiting for the request body.

  • 2XX – Success

The 2XX range notes a range of successes in communication, and combines several responses into specific codes. The first three status codes excellently determine this range, like 200 OK means that a GET or POST request was successful, 201 Created indicates that a request has been brought to completion and a new resource has been created for the client, and 202 Accepted shows that the request has been accepted, and that processing has begun.

  • 3XX – Redirection

The 3XX range is all about the status of the resource or endpoint. When this kind of status code is sent, it confirms that the server is still accepting communication, but that the contacted point is not the accurate point of entry into the system. 301 Moved Permanently denotes that the client request did reach the correct system, but this request and all future requests should be managed by a different URI. This is very convenient both in subdomains and in moving a resource from one server to another.

  • 4XX – Client Error

The 4XX series of error codes is probably the most well-known because of the famous 404 Not Found status, which is a prominent marker for URLs and URIs that are formed in the wrong way. However, other more useful status codes for APIs are in this range.

414 URI Too Long is a common status code, indicating that the data pushed through in a GET request is too long, and should be changed into a POST request. Another common code is 429 Too many Requests, which is used for rate limiting to note a client is attempting too many requests simultaneously that their traffic is being rejected.

  • 5XX – Server Error

The 5XX range is reserved for error codes notably related to the server functionality. Whereas the 4XX range is the client’s responsibility (meaning that it is a client failure), the 5XX range explicitly notes failures with the server. Error codes such as 502 Bad Gateway, which marks the upstream server, has failed and that the current server is a gateway, further reveal server functionality as a method of showing where failure is transpiring.

Making a Good Error Code
With a strongly-built comprehension of HTTP Status Codes, we can start analyzing what actually makes for a good error code, and what makes for a bad error code. Quality error codes not only convey what went wrong, but also why it went wrong.

Excessively obscure error codes are very inconvenient. Imagine that you are trying to make a GET request to an API that manages digital music inventory. You’ve submitted your request to an API that usually accepts your traffic, you’ve passed the correct authorization and authentication credentials, and you think the server is ready to respond.

You send your data, and receive this kind of error code: 400 Bad Request. Without additional data and without more information, what does this mean? It’s in the 4XX range, so you know the problem was on the client side, but it doesn’t explain and solve anything, other than “bad request.”

This explains that a “helpful” error code is not as helpful as it should be. We could easily make that same response helpful and clear with less effort. Good error codes must pass three essential criteria in order to be functional, such as:

  • An HTTP Status Code, so that the source and realm of the problem can be confirmed with ease;
  • An Internal Reference IDfor documentation-specific notation of errors. In some cases, this can substitute the HTTP Status Code, as long as the internal reference sheet inserts the HTTP Status Code scheme or similar reference material.
  • Human readable messagesthat conclude the context, cause, and solution for the existing error.

From this discussion, we can conclude that error codes are useful if inserted with messages conveying what goes wrong and why it goes wrong, topped off with the human readable messages emphasizing the solution that we can take and do to handle it. That way, we can effortlessly handle it when future errors occur spontaneously.

Things that can be cached in WordPress Cache

WordPress Cache What can be Cached and How We Do it

Caching is one of technologies which can contribute to site speed. Besides, caching will enable your stored data to be available for future requests. Some web developers might be familiar with it, some might not. But, if you haven’t been familiar with caching, you can learn more about it in this article. This article will explain what WordPress cache is and how it can be implemented on many different levels.

What is Caching?
In computing, the word “cache” is quite familiar. It refers to software or hardware component which is temporarily used to store values and retrieve them faster in the future. Values include MySQL queries, or compiled PHP bytecode as well as duplicate data, such as HTML and images.

In fact, we can gain a significant performance advantage by making copies of data and placing them in the “caching” component. This is because your visitors can retrieve cached content much faster than un-cached. Besides, your performance improvement can enhance depends on how much data that you can cache.

Things that can be cached
There are several levels, depending on how far you want to go in optimizing your website using caching. Here they are:

  • HTML Output
    You can find many plugins that can help you cache the HTML page itself. For instance, you can use WP Rocket and W3 Total Cache that can perform cache and many more. These plugins cache the result of the HTML output saving time for future requests. In fact, you can serve uncached content for every plugin have a cache invalidation mechanism.
    You can also try to “minify” HTML to make it smaller. This will add up a couple of kilobytes per page and keep increasing over time.
  • PHP OpCache
    A technique which PHP takes the source PHP files and compiles them into an intermediary form called bytecode is named OpCaching. Bytecode is like a computer’s machine code, but it refers to machine code that is executed by a “virtual machine” rather than by a real one. Fortunately, it can be executed quicker than having the PHP interpreter parse a command at a time since it is machine code and resides in memory.
    At a certain level, caching stores these bytecode data into memory, this causes your application gets executed faster. Besides, in order to have PHP OpCache enabled, you need to have access to the PHP configuration file.
  • PHP Object Cache
    This cache is done on the language’s OOP level. It uses the concept of “objects” to describe logic, data, and ideas. Objects are constantly being created and destroyed as your application runs. This technique solves the problem by caching the objects themselves.
    You can find PHP object cache in Memcached and the assorted ones for Redis. However, in order to enable PHP Object caching, you need to have access PHP configuration.
  • MySQL Query Caching
    The idea might be the same with PHP object cache, unless it is applied at a database level. A set of data are returned by the database based on the query that was entered. In fact, someone can get data much faster if someone has called the same data first. This is because they would reside cached in memory. But, you need to have access to the database server.

7 Pop Ups Tricks to Avoid Hurting Your SEO Efforts

Blog5June-01

Using pop-ups add in your website can be a confusing task. Especially since, Google’s mobile has just released its new update, Google’s mobile interstitial penalty. Many web developers are still arguing whether to use or not to use pop ups. In this article, we reveal 7 simple tricks to minimize the risk for using pop-ups without harming your SEO.

  1. Understand Which Interstitials are No-goes

Lately Google’s mobile interstitial penalty has become one of the most popular updates. “Interstitial” is a broad term that refers to most pop-ups, overlays, and modals. However, not all interstitials are considered equally intrusive.

As a general rule of thumb, your mobile page may be devalued if your interstitials are spammy, difficult to dismiss, or diminish your users’ experience. In addition of mobile indexing, this will hurt your positions in the SERPs.

Below are examples of interstitials that make your content less accessible:

  • Content-covering pop-ups which users are forced to close it before they can continue reading.
  • Standalone interstitials that appear before users can access your content.
  • Deceptive page layouts whose above-the-fold portion looks like an interstitial.

Moreover, there are some ads that Google’s known to dislike and has penalized in the past, including:

  • Classic interstitial ads and splash ads that interrupt users since they navigate between pages or before they reach your homepage.
  • Annoying window pop-ups that appear as soon as a user clicks on your page.
  • Welcome mats, new window pop-ups, and other intrusive ads.
  • Confusing overlay modals or easily redirects visitors who accidentally click on them.
  • Intrusive lightbox ads and pop-ups.

These don’t mean that all interstitials are forbidden for interstitials triggered by exit intent are still permitted.

  1. Continue Using Non-Intrusive Interstitials

If Intrusive interstitials are bad, non-intrusive interstitials are oppositely good for your SEO. Non-intrusive interstitials are information such as age verification interstitials, and cookie use notifications. It also includes other pop-ups, such as banner ads; slide ins, in lines and tabs. This is because they take up only 15 percent or less portion of the screen than it is recommended.

The important thing is to avoid covering all of your screen with full-screen overlays, welcome mats, and ad modals. Instead of using them, you can use other options, such as top banners and slide-in boxes.

  1. Switch to Timed Pop Ups

If you have to continue to use pop-ups and overlays, you can try to redesign and change the timing of your interstitials. For instance, you get used to place a pop-up right after a user lands on your page. Now you can display the pop-up before your users leaving your blog post.

Another idea is to limit how long pop-ups are displayed. A pop up that can automatically close after several seconds is way better than one that should be closed.

  1. Watch Out for “Gray Area” Interstitials

You might be surprised that some interstitials might be devalued as Google consider them as intrusive interstitials. They are sticky sidebars, related posts, share button, live chat boxes, and coupon pop-ups. Even though, they may not produce big negative impact on your SEO, but you better avoid them than sorry.

  1. Use Permitted (but Intrusive) Pop-ups cautiously

There are some ads that are definitely interruptive but aren’t penalized yet. This is because Google will inspect them later.

  • Page-to-page interstitials: We all know that Google values good UX, but page to page interstitials are not good UX.
  • Interstitials triggered by exit intent: Pop-ups triggered by exit intent aren’t penalized by the new update. To avoid landing on the wrong side of the interstitial penalty, you can place a no index tag in your code.
  1. Intrusive Ads on Desktop is still Allowed

The easiest way to solve this problem is by hiding pop-ups on mobile devices. However, you can keep using them for desktop visitors. In fact, you can find some pop-up plugins that allow you to display your ads on any particular platforms. However, this is not a permanent solution as intrusive pop ups would diminish your UX. Therefore, it could be penalized under a future update.

  1. Restrict Pop-Ups to Sources Other Than Google Organic Search

Another way to avoid the interstitials penalty is by finding your websites from other sources outside Google organic search results. In addition, don’t feel too pressured to switch, if organic search drives a lot of your traffic and it generates leads. Bear in mind that useful content is above the other things, so one or two interstitial ad won’t lose a website.