Why You Should Avoid Integration Through Redirection
This is a guest blog from Jason Hunt of IBM:
Many of you may be familiar with HTTP redirection, also called HTTP forwarding. HTTP redirects were originally intended for cases where a web page had moved and you wanted to send the user automatically to the new location of the page. Two response codes from the HTTP specification are primarily used for this situation:
– 301 – for a page that had moved permanently
– 302 – for a page that had moved temporarily
Developers soon realized that they could use these status codes to offer new services. The idea is simply, “call my service first, I’ll perform the service, then I’ll send the user to where s/he is supposed to go.” The easiest example of this is URL shorteners, which take a relatively short URL (handy for posts to social media) and then redirect the user to the original, long URL.
Additional services are now also offered through redirection. For example, marketing campaign trackers might send an e-mail newsletter with all the links pointing to the marketing service. When the user clicks a link in the newsletter, the marketing service will track who clicked which link, and then redirect the user to intended content.
While these redirect services can be handy, it’s easy for a developer to fall into the trap of what I call “integration through redirection.” In this anti-pattern, your application architecture becomes a series of back-end calls chained together through redirects. This can be problematic, particularly for mobile users, where a series of redirects can greatly increase latency and reduce user experience.
To get an idea of how big of an issue this can be, I found an example of a major newspaper that used 4 redirects just to show a news article. Using the ARO tool, I was able to identify each of the hops:
- URL Shortener #1
- URL Shortener #2 & Analytics provider
- “Normal web version” of article
- Mobile version of article
- Mobile version of article on the US site
In my test (on an older smartphone, but on a wifi network), it took 2 seconds from the first request until the actual article response was sent. As a comparison, the last request (for the actual article) only took 260 ms. So, 87% of the page load time was spent on integration-through-redirection!
A much more efficient way to integrate services is via one call to a server and let the server (over its low latency network) make all the necessary back-end and service calls. The server may even be able to do these calls in parallel. You can find this architecture in many mobile application development platforms. At IBM, we call this “mobile middleware” and support this architecture in our IBM Worklight platform.
IBM Worklight Server interaction diagram
So, if you’re looking to leverage third party services in your mobile application, keep an eye out for overuse of redirection and consider integrating at the server, rather than on the mobile device.