4

Using a REST API for front-end code is a desiderable and quite common practice.
However, I was wondering if using it also for the back-end could be a good choice.

What I mean is leaving the burden of retrieving data from the database all to the API, and then call it from other parts of my back-end (mainly views and controllers) whenever I need to query the database, instead of doing it directly.

One thing I'm really concerned about is sharing some code between front-end and back-end, and using the API as a common source of data would be very handy.

So the question is, are there some reasons which make this a bad idea?

5

Decoupling components from the database / getting away from direct database connections is a common pattern. Moving access into middleware / a component that front-ends the database can help improve security and modularity, and provide a place to implement data validation and interpretation that would otherwise "fall into" SQL, stored procedures, and client-side database code. Against this you have to weigh the development, runtime, and possibly economic cost of that middleware / data mangement front-end. But at many project scale-points, data front-ends are often considered a good choice.

If you control the backend design and components, using a RESTful API--especially in its common format, e.g. served by HTTP and encoded with JSON--is notably inefficient compared to other alternatives (e.g. direct library linking, Protocol Buffers, Thrift, various kinds of ESB, other RPC mechanisms, ...) that do not go through a serialize-to-text, serve, deserialize-from-text cycle for every API call. REST is also semantically better as an arms-length interaction mechanism, given that some constructs (e.g. multi-step transactions, streaming, large binary objects, raising exceptions, guaranteed delivery, ...) are more simply, cleanly, or directly handled with other forms of interaction.

Some reasons you still might want to use a RESTful backend: simplicity, consistency (every client, local or remote, goes through just one API), and time-to-market (e.g. not needing to learn another API/interaction style). These assume that you are exposing your database, relatively directly, through the RESTful API. If it is strictly for the use of components under your control, REST is probably not the best choice (for either semantic richness or efficiency).

  • Thank you for the answer! And yes, one of the main concerns is inefficiency and I am thinking about a way to abstract the access layer from the API implementation, so I can access it in a REST-fashion but directly from the code, thus eliminating all the overhead due to HTTP – mattecapu Nov 8 '14 at 20:44
  • 2
    This is s great answer. If you keep your REST controllers thin and only responsible for "parse request, call business model class lib, return result", then it's perfectly reasonable to call that library directly. Just beware non-http related logic in your controllers. – RubberDuck Apr 12 '17 at 0:36
3

I think the overarching justification out of making data access a RESTful API would be the relationship the data access would have to the rest of the environment.

Think about it, the power of the API is typically the vast amount and variety of "client" implementers that can consume it. That should be no different in your case.

In other words, if you were to have multiple consumers and different invokers of this same data access and/or looking to scale that out, then I think it would make sense.

But conversely, if you have a single consumer and this data access and logic is tailored very specifically so it doesn't scale, I don't know what you would gain out of making the transfer of bits through a RESTful API.

0

Not necessarily. Middleware cannot handle everything. There are three examples I always bring up to show this: batching, forwards and api chaining. These all benefit by staying within the bounds of the original request but in applications, often have to leave and come back in via the proxy/api gate.

By abstracting I/O from the api and moving it to an interceptor, you can use a prehandler/posthandler to hand off the communications and use one thread to handle the loop.

The the I/O flow from api gate to application instance to response tooling is one constan flow and isn't broken.

See api abstraction and api chaining for more information (http://www.slideshare.net/bobdobbes/api-abstraction-api-chaining)

  • "The community here tends to vote down overt self-promotion and flag it as spam. Post good, relevant answers, and if some (but not all) happen to be about your product or website, that’s okay. However, you must disclose your affiliation in your answers." (Help Center > Our model > How to not be a spammer) – gnat Dec 13 '14 at 22:32
  • It's open source scientific research that I am often asked to present at SpringOne, Apple, Amazon, Mashery, Paypal and other institutions. What am I supposed to put down as my affiliation? Self :) – Orubel Dec 18 '14 at 15:56
  • I understand what you are saying entirely. People frown on self promotion/evangelism. But you can't at the same time quash it without quashing scientific discussion of new ideas. You have to be careful both ways... it's a tricky situation bit I hear you. – Orubel Dec 19 '14 at 16:37
0

Using the REST API from the backend has two advantages: You don't have to develop and document another API, and you only have one set of bugs, not two.

There are two possible objections: It could be that your backend does things that don't fit in with the existing API (because it may look at the data from the opposite direction as the frontend API does). And there might be performance issues: If the backend uses the database ten times more than the frontend does, and that is performance critical, then you don't want the simplest API, but the fastest.

So check how your backend will use the database and decide from there. If your backend is happy with the REST API functionality and there are no performance problems, use the REST API.

  • Even if the backend is happy. Is it worth to expose all the access to the db to the Falacies of the distributed computing? – Laiv Apr 11 '17 at 20:05
0

A lot of good answers and comments. To me, it seems microservice oriented. The challenge is that there is slight overhead inserting a layer between your data access and the backend code that churns on that data. Overhead in terms of development time & cycles, and overhead in terms of code performance. But the upsides are that your application components are more loosely coupled so you can extend/change the code with less complexity. If everything that accesses the data does so through the API, then any changes you need to make to the underlying data model if you make the API handle seamlessly then you are done.

On the contrary, if several parts of your code are accessing the data in several spots, you have more to consider and do and test. Also, when there are multiple places where backend code accesses the data, there tends to be inconsistency.

protected by gnat Feb 23 '18 at 6:51

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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