16

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)?

  • 3
    A REST API is not a database access protocol, so the question is a big of a category error. A REST api is a document store. It MIGHT use a database on the server side (or it might not). If you have no need for a REST API then obviously don't use one. But then that goes for everything. If you don't need a database don't use one, writing to file system will be faster than a database. If you don't need a file system don't use one, writing to RAM is faster than disk. If you don't need RAM don't use it, writing to CPU cache is faster etc etc etc – Cormac Mulhall Jun 17 '15 at 10:40
  • 1
    The "on the other hand" requires you to expose your database to the big bad world. – Pieter B Jun 17 '15 at 11:35
  • @PieterB: No, the "on the other hand" is exposing the database to the web app which is trusted. – JacquesB Jun 26 '15 at 7:02
  • @JacquesB and the web app runs on the clients computer. So it shouldn't be trusted because it could be a modified version. – Pieter B Jun 26 '15 at 8:14
  • @PieterB: The question does not state anything about the web app running on an untrusted server. That would be a highly unusual setup. – JacquesB Jun 26 '15 at 8:22
18

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.

  • +1 for mentioning caching. Although it is doing extra work. But actually it could be faster by caching repeated query. – Yana Agun Siswanto Jun 15 '15 at 6:05
  • 3
    @Klee Your answer is not quite right. »Introducing a REST service if it's not required will slow the execution down as the system is doing more.« Not in every case is there traffic to the endpoint at all, if e.g. a reverse-proxy could handle cahced results. – Thomas Junk Jun 15 '15 at 10:40
  • @klee The reason I asked this question was from this SO post programmers.stackexchange.com/questions/277701/… - one answer talks about how Amazon had great success by using a fully RESTful system instead of direct access. Just got me thinking... – Micro Jun 15 '15 at 14:06
9

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!

6

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.

  • 4
    If the data is cacheable in a rest service layer, then it is cacheable in the web app, which would be much better for performance. – JacquesB Jun 15 '15 at 12:45
  • The fastest way is, not hitting the web app at all. – Thomas Junk Jun 15 '15 at 12:58
  • 1
    And just to make it more interesting, not all "hits" to the database are equal if you can access in memory v. the disk. – JeffO Jun 15 '15 at 14:47
  • @ThomasJunk: If I understand the original question correct, the client is a web app, and the question is if the web app should connect to the db directly or call through a rest service. – JacquesB Jun 18 '15 at 15:45
  • 1
    That doesn't change anything on my answer. Calling a REST-Service includes calling out to a Web-Server which is could be behind a reverse proxy where possible answers could be cached - as I already said. – Thomas Junk Jun 18 '15 at 20:36
2

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.

1

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.

-2

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.

  • 1
    »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.« If that means slower in execution, that is not right. – Thomas Junk Jun 15 '15 at 10:42
  • 1
    Aren't there situations where accessing the database is a bad idea aside from just portability? Sometimes having a REST API etc can keep more logic (and better security?) on the server side, right? – J Trana Jun 16 '15 at 1:06
  • @JTrana that can be yes or no, really depend on how you do thing while introducing extra layer can provide extra layer of security, adding extra layer also mean that you have more chance to screwed something up and expose security hole. I think the point of Web API is to expose your "API". Big application like Facebook,Amazon,Google that need to provide access to 3rd party and have a lot of platform must have Web API, but for small application you need to think twice before doing it. – kirie Jun 16 '15 at 3:02
-2

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

  • 2
    -1. While there's no "need" to create an API, not creating a DAL often leads to enormous pain should a change of database backend be required. Also no reason why if you have the DB "offline" that the Rest service couldn't be made available there too. – James Snell Mar 10 '16 at 21:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.