Breaking the Barriers of Request Length

The efficiency of the Ajax based application is largely based on the ability of the application to process as much data as it could the fastest time possible. Through correct coding, developers would be able to ensure smooth flow of data. The standard JavaScript coding which usually include the basic functions from the client side to basic XHR compatibility should be able to run in different browsers.

But the simplified coding of JavaScript is usually geared towards smaller applications. The main culprit: the GET function. This function extracts information from its source and sends them to the client side. While doing this process, the browser caches the data for faster data retrieval.

Through continuous caching, the data will eventually clog the browser and slow down the online application. Because of this common problem, the browser will often inhibit the function to extract large amounts of data. When GET comes with a very long request for data processing, the browser will prevent the function from going further.

The application eventually stops working. Some work around this problem by refreshing the entire webpage so that cache will be controlled. But this actually defeats the purpose of having an Ajax based application – instead of controlling some of the parts of the webpage through JavaScript; the behavior becomes HTML-like.

Using POST

A good solution to this data request problem is to use POST instead of GET. As already indicated, GET behaves as the name suggest – it just gets the data. The GET function does not care if the data is already there, it will continue to request the same data.

Eventually the cached data will quickly increase since GET extracts the same data each time a request is made. That is why developers try (and usually fails) to have a lengthened request with the use of GET hoping that the process will go through (which will not).

POST on the other hand, has a totally different interaction with the browser. Although it will still be cached by the browser, it has a unique behavior that ensures the application works without clogging the browser with cached data. POST updates the data cached in the online application.

Instead of starting over, developers would just use multiple POST functions so that the browser will continuously update the data. The application will continue to function without any problem even if there is massive request from users.

The reason why GET is often preferred first than POST is from the fact that GET is a lot easier to be implemented compared to POST. Developers could just target the source, use the function GET and target a part of the client side on where the function should be implemented. POST on the other hand has to go through the process of updating the cached data before anything could be implemented in the client side.

If you are building a simple Ajax based application, GET is still a viable function for data extraction. On the other hand, POST should be considered so that large requests would be possible.