How to avoid overloading HTTP requests when consuming REST APIs?

Question

How to avoid overloading HTTP requests when consuming REST APIs?

Navigation

#1 by (10 votes)

9

I have a REST API made with Laravel and a WebApp (which uses the features of this API) made in Angular.JS. My WebApp is a unique registered user portal, but now I'm creating a website so that non-registered users can only check out a few things.

I decided to make a normal website because this way search engines can more easily index the site and this should help improve the site's position in Google search results, for example.

In the meantime I'm facing a big problem now. My idea was for the site to leverage the features that the API already provides (so you do not need to make new deployments). So far so good, it worked, but it was soooo slow due to HTTP Request overhead. Basically when a link is clicked on the site an HTTP Request is generated and when the server fetches the content in the API another HTTP Request is generated.

In my local development environment, simple access to a page with a list of items provided by the API already takes 2.5 seconds, making me very concerned about the performance this will have in other scenarios. In the end it seems to me that it is very advantageous to have an API for WebApps and for Apps but very bad for Sites.

My questions are : How to resolve this situation? Is this a price to pay for using an API? Is there anything I can do to avoid this overload of requests? Any plugins, packages, or network schemas?

api rest http laravel

asked by anonymous 12.10.2015 / 14:06

1 answer

Why does the compiler create repeated .class files? How do I store settings for a site?

score 10 · Answer 1

This is a more architecture issue than REST APIs. Any applications, technologies or platforms that do not take into account possible usage loads can become slow.

One of the techniques that applications with high data traffic use is caching , or temporary storage. The idea is to prevent access to resources that consume processing time or go into standby (such as access to a database, disk and LDAP, for example).

Some levels of caching that you can implement:

Bank : If your application is spending a lot of time waiting for the response from a query or stored procedure , consider reasonably static search results on temporary tables (also called staging tables ).
DAL (Data Access layer) : Whenever possible, implement a mechanism that stores the result of queries made to the database in memory ( MemCached , and Redis ) and re-use the result obtained instead of consulting again.
Distributed caching : If you have multiple servers performing basically static queries on the same database, use a distributed caching mechanism to store your data. This will allow only one query to be made to the bank.
GET operation result cache : You can add a header to the response saying that the value will not change for a certain period of time, thus preventing new requests coming from the web application.

You can also implement several of these techniques in parallel.