As you likely know, when our RESTful API first launches it’s almost always quick to respond and returns just enough data. Over time, this changes though and nobody will want to wait for slow responses or deal with too much data especially if we didn’t design for REST API Constraints.
Optimization can mean a lot of things like simplifying a process, reducing data and even speeding up response time.
An API often has three different ways we can optimize it:
- Reducing the data returned / reducing the data sent
- Reducing the response time
- Improving caching
Simplifying responses and improving speed has a dramatic impact on efficiency and cost. In business, reducing cost and time has a dramatic impact.
Reducing Data Returned / Reducing the Data Sent
One of the my top recommendations for improving a RESTful API is to avoid returning unneeded data, and avoid unnecessary database joins. Using techniques like HATEOAS can remove a lot of clutter and make integrating with your API much easier.
Filtering
Filtering allows us to remove records that aren’t necessary on a list/or collection endpoint. If I was working on an ecommerce website for a bookstore like Amazon that would be an endpoint like /books .
Maybe I would only want books published this year, so I do a GET to an endpoint with a query string /books?year_published=2022.
Pagination
When large lists of records are exposed through an API, we need a mechanism to control how many records are returned.
Paging is very common when dealing with collection/list endpoints. A collection or list endpoint should be any endpoint that is a plural noun like “books” or “activities”.
There are a few different ways to implement paging, the blog article Implementing Paging in a REST API goes into more detail.
Sorting
Sorting and Paging together allows us to reduce the amount of unneeded data that is returned through the API.
See the blog article Sorting in a REST API for some ideas on how to implement sorting in a REST based API.
Reducing the Response Time
Response time is often extended by not responding quickly enough. Where possible, it usually makes sense to use Message Queues and put things into the queue and not wait for the response.
One case where this makes a lot of sense is the case of reporting. Reports can be generated asynchronously and then emailed to the user to download later.
Improving Database Response Time
Databases are usually the main cause of poor API performance, so they can have a dramatic impact on the customer experience. Data retrieval can be dramatically impacted by a poorly written database query or indexing issue.
When looking to optimize queries the first thing to do is look at the database performance using a query analyzer. Look at how the queries are being optimized in the engine, are there unnecessary joins that are being done?
Are there a lot of SELECT * FROM which is returning a lot of unnecessary data? Are you using indexes when doing queries?
Improving Caching
Caching allows us to avoid regenerating the same response twice, it will make API requests appear faster and allows us to save some server results.
Caching is one of the most important RESTful constraints for an API that is about to handle large scale. Caching Requests starts with using the right headers, and not being scared to invalidate the cache.
Caching a database can be done using in memory stores like Redis or Elasticache – it’s a great way to avoid hitting the database for data that changes infrequently.
Wrapping It up
In this blog article, you learned about different approaches to Optimize an API. Optimization is a systematic approach that we take to improve the speed or usage of resources.
Also published on Medium.
