erotsppa
erotsppa

Reputation: 15021

How to optimize HTTP API?

We've built a huge API using HTTP to our php server from applications clients. The API is simply done in php with POST parameters. However we are looking for ways to make the API call faster as the clients are on mobile devices. What are some things that we can do to optmize it?

1) I hear REST API is very popular and used by big companies. How do I make my HTTP POSTS into a REST API?
2) How do I minimize the amount of HTTP headers and overhead?

What other steps we can take to increase the speed of the API call?

Upvotes: 0

Views: 1441

Answers (2)

fumanchu
fumanchu

Reputation: 14559

REST is an architectural style, and has guided the design of HTTP. One of the ways it has done so is via the cache constraint, which trades a bit of latency for a lot of efficiency; that is, a few requests pay a little bit of extra overhead for a caching component so that the vast majority of requests never hit the network at all. When done thoughtfully, this approach can vastly improve the efficiency of your network application.

Unfortunately, switching architectural styles gets more and more expensive the later in your project lifecycle you try to do it, and it sounds like you've not only already designed your system but already built it. It also sound like one of your design goals is extremely low latency; I highly doubt that the REST style fits your design goals.

So we're left with optimizing what is essentially RPC over HTTP. That can be accomplished via the following techniques (and probably others I'm not aware of):

  1. Compression. You can "gzip" your responses and declare them via the Content-Encoding response header. See http://www.webcodingtech.com/php/gzip-compression.php, for example, to do so in PHP.
  2. "Minification". Shrink the size of your HTML, Javascript, and CSS by taking out insignificant whitespace, and mangling variable names, etc. There are good tools for this all over the web.
  3. Optimize images. Either by size or by compression ratio.
  4. Header wrangling. Even if you're not using the REST style, HTTP is still optimized for large-grain payloads. For the vast majority of responses, the size of the headers is insignificant compared to the size of the response body. However, some tiny responses might fit under the typical 1500-byte MTU if you have complete manual control over the headers your web server emits. Not all server-side web frameworks allow this, however, and make sure you're not stripping out headers which are required for proper interoperability.
  5. Push less information to mobile clients. Break up large pages and link them instead. This will work better with the screen real estate on mobile clients. Sure, it'll play havoc with servers and proxies, and eventually melt down the Internet as the overall efficiency degrades, but you can let your kids worry about that. Provide links to the "non-mobile version" for power users.

Upvotes: 1

billygoat
billygoat

Reputation: 21984

REST frameworks (and hence the api) is just a wrapper around simple http calls. The framework is aimed at maintaining the REST architecture principal (Google Roy Fieldings rant on what is not REST) and also to encapusulate some low level behaviors like Response encoding, marshaling, un-marshaling etc.

So what I am trying to say is REST frameworks will not help making your application any faster than it already is. It will just make programming a bit easier.

As far as HTTP Header is considered, HTTP header should only contain processing and meta information (like auth and accept). What else do you have in http header. ( This is where framework can help, for instance it can process the accept parameter for you)

Upvotes: 2

Related Questions