What is faster? Using REST API or querying a database directly?

Question

What is faster performance wise? Creating a REST API and having your web app use the REST API to do all interactions with your database OR querying your database directly (i.e. using whatever typical object your language uses to query a database such as JDBC for Java)?

The way I see it with REST:

1. You make an object in your code to call the REST method
2. Call http method
3. Code inside your REST API queries the database
4. Database returns some data
5. REST API code packs up the data into Json and sends it to your client
6. Client receives Json/XML response
7. Map response to an object in your code

On the other hand, querying a database directly:

1. You make an object with query string to query the database
2. Database returns some data
3. Map response to an object in your code

So wouldn't this mean that using a REST API would be slower? Maybe it depends on the type of database (SQL vs NoSQL)?

Answer 1

When you add complexity the code will run slower. Introducing a REST service if it's not required will slow the execution down as the system is doing more.

Abstracting the database is good practice. If you're worried about speed you could look into caching the data in memory so that the database doesn't need to be touched to handle the request.

Before optimizing performance though I'd look into what problem you're trying to solve and the architecture you're using, I'm struggling to think of a situation where the database options would be direct access vs REST.

Answer 2

If you're concern is speed, then yes a Rest service will be slower for the reasons stated above. However, speed of the type you describe is rarely the primary concern and if it is, can be addressed in other ways. Premature optimisation is the root of all evil.

Consider if your primary concern is interoperability (mobile, web, B2B), now REST is very attractive because it is technology agnostic.

Suppose you code for a database. What would you do if you choose to change your underlying data store. How hard would it be to do if you are tightly coupled to the underlying store?

The real answer is it depends, but hopefully I've given you some things to think about!

Answer 3

If find it hard to answer this question.

The correct general answer should be: it depends.

The way I see it with REST:

1. You make an object in your code to call the REST method
2. Call http method
3. Code inside your REST API queries the database
4. Database returns some data
5. REST API code packs up the data into Json and sends it to your client
6. Client receives Json/XML response
7. Map response to an object in your code

There is a mistake in your thought.

And this mistake stems from the fact, that you do not fully understand REST and its principles. REST was not invented, because some nerds found it cool (of course it is) to send Javascript-objects via HTTP over the wire. The main advantage of using HTTP is the possibility of using Caching. If you make your results cacheable, then there are less requests to be made to the DB. And no marshalling is involved. The answer could be delivered directly.

Insofar @Klees answer is not quite right:

When you add complexity the code will run slower. Introducing a REST service if it's not required will slow the execution down as the system is doing more.

When dealing with cacheables results, there is no impact on your application: delivering known answers to known questions could be done via reverse-proxies.

Answer 4

It depends.

Obviously, the more layers in your code the slower it goes. But... there comes a point where direct end-to-end performance doesn't matter as much as scalability. If you have 1 user accessing your database on a local PC, it can go fast. If you have a thousand users accessing the same DB on the same PC, chances are you're going to see them all get frustrated. The solution is to move the DB to another box, add a layer in the middle and although for 1 user, it will perform slower, when the thousand access it, it will go faster. (that's a simplistic answer but true in principle).

There are other reasons to hide your DB behind a middle tier layer, such as security.

Answer 5

Introducing an extra service tier always have a cost in complexity and performance overhead. There are some specific kinds of architecture where introducing a shared service tier (like a REST API) may improve perforce due to shared caching - but it sounds like it is not the kind of architecture you have.

Consider an architecture where you have multiple web apps or multiple desktop apps connecting directly to the same database. If they perform the same queries often, it may improve performance to cache query results in a shared service. Especially if you have say hundreds of desktop apps accessing the same database directly (not through a web app!) and performing the same queries, there could be a major improvement. However, even in this architecture, the primary reason to introducing a shared service would probably be security and data abstraction rather than performance.

But it sounds like you have a single web app which connects to the database directly. In that case there is no benefit to introduce an additional service layer. Caching, database abstraction etc. could be handled at the data access layer in the same application.

Answer 6

I don't know where you get lost, but it is pretty clear, when you're using REST API you are doing extra step, and extra step "always" mean slower when programming involved.

There's pros and cons, but if you can access database directly from your application it always better to call it directly instead of using Web API, of course if you use Web API you can easily port your application to different platform.

Answer 7

REST :

• open to multi frontends and 1 backend
• need to create your own API (or use one like Loopback)
• not working offline

Local DB :

• not opened to 'tiers', they need to have access to your backend to synchronize
• no need to create an API, use DB interface
• working offline

THIS IS QUITE HUGE DIFFERENCE, PEOPLE OFTEN FORGOT THESE POINTS